Skip to content

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