Premature optimization involves trying to improve something—especially with the goal of perfecting it—when it’s too early to do so. For example, a software developer could engage in premature optimization by spending a lot of time trying to write a piece of flawless code, even though it’s unclear whether this code will actually be needed.
Premature optimization can lead to various issues, such as wasted resources and increased mistakes, so it’s important to understand it. Accordingly, in the following article you will learn more about this concept, and see how you can avoid optimizing things prematurely while still recognizing situations where optimization is appropriate.
Examples of premature optimization
People engage in premature optimization in many ways and in many areas of life. Examples of this include spending a lot of resources—like time, effort, and money—while trying to:
- Improve the performance of unimportant functions in a codebase early on, even though these functions will likely be discarded or substantially changed later, regardless of their initial performance.
- Structure a startup in a way that will allow it to scale to hundreds of millions of users, before having acquired even a single one.
- Incorporate a company legally, before checking that anyone is interested in the product that it will sell.
- Pick the best possible gear for a hobby, before actually starting the hobby.
Note that, in some of these cases, whether a certain optimization is considered premature or not depends on factors such as the specific reason why it’s done. For example, if someone who’s about to start a hobby knows that they’re likely to stick with it based on past experiences, and having the best possible gear will make a substantial difference to them (e.g., in terms of safety), and they have a trusted expert who can help them pick the gear, then the optimization might be considered reasonable, rather than premature.
“Premature optimization is the root of all evil”
The concept of premature optimization was popularized by computer scientist Donald Knuth, who said that premature optimization is the root of all evil (in the context of software development).
This statement highlights the problem of premature and unnecessary optimization, for example when programmers waste time worrying about noncritical parts of their programs, and make changes that lead to issues with things such as code maintenance. However, Knuth also acknowledged that it’s important to identify and implement optimizations that are worthwhile, but this key fact is often ignored in discussions of Knuth’s statement on premature optimization.
Specifically, Knuth popularized the concept of premature optimization and the adage that premature optimization is the root of all evil in the following quote:
“There is no doubt that the holy grail of efficiency leads to abuse. 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%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.”
— From “Structured Programming with go to Statements” (Knuth, 1974), with bold added for emphasis
Knuth also made a similar statement during a lecture that he gave the same year, where he refers to this paper:
“Another important aspect of program quality is the efficiency with which the computer’s resources are actually being used. I am sorry to say that many people nowadays are condemning program efficiency, telling us that it is in bad taste. The reason for this is that we are now experiencing a reaction from the time when efficiency was the only reputable criterion of goodness, and programmers in the past have tended to be so preoccupied with efficiency that they have produced needlessly complicated code; the result of this unnecessary complexity has been that net efficiency has gone down, due to difficulties of debugging and maintenance.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
We shouldn’t be penny wise and pound foolish, nor should we always think of efficiency in terms of so many percent gained or lost in total running time or space. When we buy a car, many of us are almost oblivious to a difference of $50 or $100 in its price, while we might make a special trip to a particular store in order to buy a 50 cent item for only 25 cents. My point is that there is a time and place for efficiency; I have discussed its proper role in my paper on structured programming, which appears in the current issue of Computing Surveys.
— From “Computer Programming as an Art” (Knuth, 1974), with bold added for emphasis
Although Knuth popularized this concept, it has also been attributed to others, including Tony Hoare and Edsger Dijkstra, and Knuth himself referred to the statement “premature optimization is the root of all evil” as Hoare’s dictum in 1989. However, evidence suggests that Knuth is the one who coined the phrase.
Finally, note that premature optimization is closely related to other concepts, including the software-development principle you aren’t gonna need it (YAGNI), which denotes that you should “Always implement things when you actually need them, never when you just foresee that you need them”, and bikeshedding, which is a phenomenon where people spend a disproportionate amount of resources dealing with relatively minor issues.
Note: Optimization can also be problematic for other reasons beyond being too early, including being pointless (in the sense that it doesn’t help), offering a low return on investment (in the sense that the costs of implementing it are greater than the value it offers), and being counterproductive (in the sense that it causes greater issues than it solves). These added potential issues are discussed to some extent by Knuth when he mentions premature optimization.
Dangers of premature optimization
Premature optimization can lead to various issues, including:
- Wasted resources, for example if you spend time, effort, and money doing something that turns out to be entirely unnecessary.
- Increased mistakes, for example if you make decisions based on insufficient information.
- Worse outcomes, for example if you feel locked into a sub-optimal course of action because you want to benefit from your early optimization.
- Negative emotions, for example if you become discouraged or frustrated because all your hard work ended up becoming irrelevant.
Causes of premature optimization
People engage in premature optimization for many reasons, including the following:
- It lets them focus on things that are relatively easy for them to handle. For example, if someone wants to start a hard new hobby, then they might optimize prematurely by searching for the best possible gear, since this is easier to do than starting the hobby itself (and potentially also more fun and less scary).
- It increases their sense of progress. For example, if someone wants to start a business but doesn’t know how, then spending a lot of time optimizing the logo can give them a way to feel that they’re making progress.
- It serves as a way for them to fantasize about the future. For example, if someone wants to develop an app but doesn’t know how, then they might optimize prematurely by searching for competitions that they will be able to apply to when the app is ready, because this gives makes them feel that their app will be successful.
- They fail to prioritize properly. For example, if someone who’s developing code doesn’t properly consider the opportunity cost of their work (i.e., the value of other things they could be doing), then they might try to unnecessarily perfect unimportant parts of the code.
- They let past experiences inappropriately dictate present behaviors. For example, a student may be used to trying to get a perfect score on exams, and therefore try to create code that’s perfect during an internship, even if their efforts to do so are counterproductive.
- They’re driven by social considerations. For example, people may optimize prematurely because they want to conform to other people’s behavior, because they’re afraid of missing out on something, or because they need to look like they’re working on something (e.g., because that’s what their boss expects).
- They’re driven by other underlying phenomena. For example, people might be driven to premature optimization by the action bias, when they feel the need to act, by perfectionism, when they strive for unattainable flawlessness, by precrastination, when they rush to do things early to feel satisfaction, and by procrastination, when they work on one thing as a way to delay working on something else.
Different combinations of these causes can drive people’s premature optimization under different circumstances. Some of these causes (e.g., fantasizing about the future) can be considered motivated, in the sense that they’re driven primarily by emotional considerations—especially wanting to feel good. Such causes are contrasted with unmotivated ones (e.g., failure to prioritize), which aren’t generally driven by emotional considerations.
How to avoid premature optimization
To avoid premature optimization, you should assess situations before deciding whether and how to optimize things. In doing this, you should consider the following:
- Why do you want to optimize? For example, do you believe that this optimization will have a meaningful positive impact, or are you just focusing on it to delay dealing with something else?
- What are the benefits of optimizing? Specifically, what do you stand to gain from making this optimization, in both the short term and the long term?
- What are the costs of optimizing? Specifically, what resources will you need to spend to make this optimization (e.g., time and money), and how much of them will you need to spend?
- What else could you be doing? For example, is there something more beneficial that you could be working on?
- What are the potential dangers of optimizing? For example, could it lead you to commit to a sub-optimal course of action because you don’t yet have enough information available?
- How likely is it that this optimization will become irrelevant? Just because it might become irrelevant doesn’t mean that you shouldn’t work on it, but this possibility is something you should consider, as are associated factors (e.g., the benefits of the optimization before it becomes irrelevant).
- What are the advantages and disadvantages of waiting with this optimization? For example, is it possible that there are no downsides to waiting with this optimization until a week from now, at which point you will have more information available?
When considering these factors, it’s important to remember that not all optimization is premature. This means that rather than avoiding all optimization, you should make sure to assess the situation before deciding whether to optimize something or not. For example, even if the optimization occurs at an early stage, you might decide that it’s worthwhile, because the costs of implementing it are small but its benefits are large.
This caveat is noted in the original quote that popularized the concept of premature optimization, which 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%”.
In summary, to avoid premature optimization, you should assess situations before deciding whether and how to optimize. In doing this, you should consider factors such as why you want to optimize, what are the costs and dangers of optimizing, and what else you could be doing.
Note: When determining whether you should optimize something, a useful concept to consider is the 80/20 rule (also known as the Pareto Principle), which in this context denotes that 80% of the positive outcomes that you experience will come from 20% of the work that you do.
Summary and conclusions
- Premature optimization involves trying to improve something—especially with the goal of perfecting it—when it’s too early to do so, for example by spending a lot of time perfecting a certain piece of software code, even though it’s unclear whether this code will actually be needed.
- Premature optimization can cause various issues, such as wasted resources, increased mistakes, worse outcomes, and increased negative emotions.
- People optimize prematurely for many reasons, including that this lets them focus on things that are relatively easy for them to handle, that they fail to prioritize properly, and that they want to fit in with other people’s behavior.
- To avoid premature optimization, you should assess situations before deciding whether and how to optimize, by considering factors such as why you want to optimize, what are the costs and dangers of optimizing, and what else you could be doing.
- Not all optimization is premature, so rather than always avoiding optimizing, you should determine whether optimizations are worthwhile before you implement them.