“First make it work. Then make it right. Then make it fast.” This quotation, often with slight variations, is widely known as the golden rule of programming. As far as I’ve been able to ascertain, the quotation is attributed to Kent Beck, who credits his father with it. Being widely known makes the principle no less important, particularly because it’s more honored in the breach than in the observance. A negative form, slightly exaggerated for emphasis, is in a quotation by Don Knuth: “Premature optimization is the root of all evil in programming.”
Optimization is premature if your code is not working yet. First make it work. Optimization is also premature if your code is working but you are not satisfied with the overall architecture and design. Remedy structural flaws before worrying about optimization: first make it work, then make it right. These first two steps are not optional—working, well-architected code is always a must.
In contrast, you don’t always need to make it fast.
Benchmarks may show that your code’s performance is
already acceptable after the first two steps. When performance is not
acceptable, profiling often shows that all performance issues are in
a small subset, perhaps 10% to 20% of the code where your program
spends 80% or 90% of the time. Such performance-crucial regions of
your code are also known as its
hot spots. It’s a waste of effort to optimize large portions of code that account for, say, 10% of your program’s running ...