Antipatterns — Premature Optimization

Premature optimization is when programmers tries to optimize the programs at a stage when it is too early to do so.

Why premature optimization is bad for the Indian cricket team?

As I am a big cricket fan, I will try to explain premature Optimization by giving example of a cricket match. Once the Indian cricket team needed 350 runs in 50 overs but lost three wickets for 40 runs in just 4overs. The Indian batsmen were still playing aggressively trying to improve the run rate and that resulted into losing more wickets. As a final result Indian cricket team lost the match!!!

The question is, should Indian players play aggressively even if they lost 3 wickets in 40 runs?

How Indian team confronts such situation?

What should be the strategy of the Indian cricket team? Obviously, the Indian team will not concentrate on the run rate at the early stage, they will try to preserve the wickets so in the last few overs of the match the Indian cricket team can increase (optimize) their run rate by playing hard. The Indian cricket team followed this strategy and won the match.

Same is applicable to the software development.

Some signs and examples of premature Optimizations:

· Spending lot of time and resources for optimizing the certain functions and/or functionalities in an early stage of development. Optimization effort go in vain many times due to changes in the code/functionality. So, if you ask me opinion optimization should be considered cleverly.

· Spending lot of time and resources to handle 1000’s of OPS (operations per seconds) for millions of users, before enlisting even 100 users.

· Spending lots of time and company resources to develop a product without knowing whether anyone wants the developed product or not. So, user feedback should be prioritized first.

In DonaldKnuth’s paper “StructuredProgrammingWithGoToStatements”, he wrote: “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. Yet we should not pass up our opportunities in that critical 3%.”

tl;dr :

Spend time on optimization only after double checking, whether the optimization must be required at current stage of development. Do not optimize the part of the code or functionality that likely to be changed during development stage.