Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Technology Audit of What’s Up at Work

Technology Audit of What’s Up at Work

The Good

  • In general, the technology choices are sound
    • Git, Python, Django, PostgreSQL, Gunicorn, Sass, Bootstrap, and nginx are all excellent technologies
    • It’s a good call to use a third-party service for sending and receiving email
    • Heroku and Amazon Web Services are both good choices for PaaS/IaaS providers
      • (although not generally at the same time**)

The Bad

The Code

  • There’s very little documentation, and what there is is disorganized and partly out of date
  • The codebase is massive (78,699 SLOC) and sprawling, and there’s no catalog or guidance provided to help one navigate or understand it
  • The JavaScript is not well organized, and is hard to navigate
  • There’s massive amounts of obsolete code, with no guidance as to what is and what isn’t obsolete
  • There’s a large amount of commented-out code, with no guidance as to why it’s commented out
  • There’s very few useful comments in the code
  • Many names are obsolete and no longer make sense given the current state of the application
    • for example, many components use the name “same customer” or “SC”, which is a prior name of the application
  • There are many redundant libraries included
    • For example: jQuery and Prototype

The Infrastructure

  • There’s no “staging” or “test” instance of the application — only the single production instance
    • This is a major problem because there’s no way for anyone other than the developer to see a change before it is deployed to production
  • The process of deploying a change is very convoluted and time-consuming
    • This is a major problem because it slows down the pace of development and deployment, and because there are multiple points of failure involved which could lead to a situation wherein an urgent update cannot be deployed
  • The application tier (nginx, Gunicorn, Python, etc.) is running on the same server as the database tier (PostgreSQL)
    • This is a major problem because it means that it’s impossible to scale these two tiers independently — which is a common need
  • Image processing (which may be limited to thumbnail generation, it’s not clear) is integrated into the application’s request-handling process, and can therefore significantly impact the performance of the website
    • it needs to be moved to an “offline” (asynchronous) processing queue
  • Generated images (thumbnails, etc.) are stored within the application’s file space, which is expensive and a management problem
    • when the disk space starts running out, the storage device (or server) will need to be upgraded — this is complicated by the fact that the application tier is using the same device/server to handle requests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment