Donald Knuth, an American computer scientist and professor at Stanford University, wrote in his paper Structured Programming with Go To Statements, “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” I couldn’t agree more.

Premature optimization increases the complexity of the software and it’s one of the reasons software projects get delivered late or fail to deliver at all. Rather than focusing on the core needs of the software, developers focus on concerns that may not matter much immediately. The new product may fail to launch, or fail to attract a large volume of users.

Not every website is going to be a Facebook. Even when Facebook was first launched, I can guarantee it wasn’t designed with all the scalability, security and performance requirements it has today. It has evolved, and it’s very likely that some parts of it were redesigned and rewritten.

Let’s imagine you’re working on a new e-commerce application like Amazon.com. You’re responsible for getting the list of products from the database and displaying it on a webpage.

Once you start coding, you might think your database query is going to be slow, especially if the database grows in size. So you may decide to implement a caching strategy along with writing your database query. A few days pass and you haven’t even managed to deliver a simple page to display the list of products. Your focus is all of a sudden shifted to building a caching framework.

Your boss or team leader asks you about the progress of the work and you still have nothing to demonstrate. You are frustrated with some strange behavior of your caching framework. Perhaps the cache doesn’t get refreshed the way you expect. You spend extra hours in the office trying to debug the problem because the deadline is coming up.

Have you ever been in a situation like this? If so, you know what I’m talking about. So what went wrong here? I’d say: premature optimization. You assumed the query was going to be slow without doing a load test. Rather than focusing only on building the product list page, your focus shifted to something that was not in the original requirements. You ended up spending your time building something that you were not asked for.

You should have focused on finishing your original task first. This would have helped you go one step forward as opposed to getting lost in the middle of nowhere. Your boss or client would have been happy seeing the progress immediately. Then you could have done some load tests to validate your assumptions about the performance of the database query.

Chances are your assumption was wrong! Then, there would be absolutely no need to implement caching and deal with extra complexity.

What if there really was a bottleneck with the query? I’d argue you could potentially optimize your query or tune your database in an hour or so. That would save you days of frustration implementing the caching framework.

What if despite all the optimizations, you still don’t get the performance you expect? I’d ask you, “Is this an immediate need for your project? Or is this going to be an issue when the number of records in the products table exceeds one million?” If the latter, why would you waste your time implementing something that wouldn’t give immediate benefit to the business? What if the website never really took off the way you thought? You’d just waste your time.

Even if there was an immediate need for caching, you’d better talk to your boss or client before implementing anything. They would know that this would push the deadline back and could decide accordingly. This way you wouldn’t be facing a lot of pressure due to tight deadlines and everyone would be happy with the results.

So, next time you’re dealing with issues around performance, think twice. Remember, premature optimization is the root of all evil! Don’t assume. Do some analysis and tests before suggesting a solution. Implement solutions only when there is a problem. You’ll save yourself (and everyone else) weeks or months of frustration dealing with complexity and tight deadlines.

Don't be shellfish...