How Premature Optimization Can Ruin Your Development Efforts

Optimization, be it code or architecture, is a touchy topic for all those involved in software development. It is quite easy to jump the gun and just modify that module or method when you believe that the tweaking will improve the processing time or make the process flow better. What must be clearly thought through is how any optimization is just an add-on but cannot be the mainstay in development.

A full-fledged debate has been raging since the 1970s ever since Donald Knuth stated that “Premature optimization is the root of all evil”. There’s a lot that has been said by those who are for it and those who don’t completely disregard it. There are many who believe that a well thought out development process will require very few optimizations rather than a poorly designed one. And there are others who believe that not all premature optimizations are evil. There is actually merit in both thought processes.
Think about this
Some of the factors that influence development efforts when putting in premature optimizations are as follows.

• What development methodology do you follow? Are you Agile? Or you are more of a Waterfall type of company? You may not agree but this piece of information also matters when making decisions about optimizations, premature or not.
• Are you an application development team or do you develop products?
  The Cost Benefit Analysis is a must before deciding whether you can afford optimizations, in more ways than one.
• Does that method really need so many parameters? Surely, it can be re-written.
  You need to think about the benefits, if any, that optimizing that piece of code will get you. Benefits like reduced processing time or reducing dependencies are important but these changes would have to be approved and planned.
• What other methods are dependent on that calculation? For every piece of code you change, you may have to retest many modules. This in return implies time and effort.
• The most important point of all, who’s going to pay for the effort put in.

These are not the only factors of how optimizations affect development. There are certain situations where optimizing the query or interface will make perfect sense. The question you should be asking yourself is whether the optimization is really going to benefit the end product or is it just something you want to add to make your code appear fancier.
Beware of the pitfalls
In Waterfall, all the requirements are defined and development plans are made well in advance. The scope of introducing optimizations at a later stage of development is not defined. The main focus is more on completing the development without compromising on the quality as much as is possible. In such cases, many customers do not push for optimizations as all they can think of is getting their hands on the software that would make their businesses better.

On the other hand, in Agile, the planning is undertaken on a sprint-by-sprint basis. So, the scope of introducing optimizations of a particular module can be planned in the upcoming sprints. This gives you some room to understand and plan the dependencies and repercussions of the optimizations.
Possible solutions
No matter what methodology is used or what sort of software you are developing, your team of architects, consultants and developers are your best shot at achieving optimal results. The experience they possess, individually and collectively, help create the software that your customers will use. This experience comes in handy when implementing the quality standards of your company.

• Enforce good development practices:
  There are certain development practices documented that can be used to write a competent piece of software. So, the terms that define what a good piece of software is, ultimately resides on your company standards. The standards must have provisions that state clearly as to what sort of optimizations are acceptable at what stage of the development cycle.
• Leave room for surprises:
  Using or combining various management methods, you can create development and review processes that would give you room to make or add any changes to your code. How late or early these optimizations can be made must be planned for.
• Talk to your customers:
  Don’t forget that your customers also have a say in implementing such optimizations. Since they are the ones who ultimately pay for the development they would not prefer to optimize in certain situations or stages of development, when all they want is a functionally sound product. Again, you must have a good understanding with your customers, if at all they are ready to accommodate optimizations and, if so, at which stage of the development. This is especially true in cases of application development teams regardless of the development process or methodology followed.

If you read the full quote from Donald Knuth, he states that “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” What it actually means is that you should not optimize because you think it will give a performance boost but that you should optimize when you can actually measure the performance gain.

Error: Contact form not found.