“Premature optimization is the root of all evil.”
— Donald Knuth
Falling into the trap of improving code performance too early over the development process almost inevitably leads to premature optimization, which is commonly regarded as something to stay away from. Let’s recap why.
By making wrong assumptions on potential performance issues before the real bottlenecks are identified via profiling, we might waste time unnecessarily optimizing code parts that will seldom be used in production.
Not only does premature optimization waste time, it also produces overcomplicated code which is harder to understand and maintain: it makes coding and debugging activities much more difficult and error prone.
Make it Work, Make it Right, Make it Fast
In the Unix world there’s a long-established saying which reads “Prototype before polishing. Get it working before you optimize it”, which Kent Beck has famously reframed to “Make it run, then make it right, then make it fast”.
The Approach in a Nutshell
- First and foremost, make it work: focus on correctness by writing and testing clear and simple code that solves the problem at hand.
- After that, make it right: refactor the working code for understandability and modularity by giving it proper structure, clear naming and commentary.
- Last, make it fast: profile the code in order to find the actual bottlenecks and optimize only when it’s truly necessary.
Summing Up
Premature optimization originates from early wrong assumptions on potential bottlenecks. Not only does it waste time, it also makes code harder to maintain.
So let’s avoid it! And when it arises the temptation of tweaking code, repeat the mantra: “Make it Work First, then Make it Work Fast”.