8 ms·

My (slightly controversial) pet peeve is the abuse of the notion that "premature optimization is the root of all evil." Sure, let's not prematurely optimize, bu

My (slightly controversial) pet peeve is the abuse of the notion that "premature optimization is the root of all evil." Sure, let's not prematurely optimize, but let's also not use that as an excuse to make horrible decisions or unforced errors also.

tomxor 6y ago
I agree but for a slightly different reason: I think the notion is also highly subjectively applicable... some types of problems really do need a lot of forethought to make efficient - waiting until later can cause significant problems when decisions are hard to pivot away from or undo. An easy example is DB design, the cost neglecting these considerations upfront can be massive and sometimes impossible to migrate away from.
- jamil7 6y ago
  I agree with both of you. This quote is often used as a crutch on which to justify poor planning. Certain types of systems are very hard to "add" performance to as an afterthought and really need to be designed around it.
cellularmitosis 6y ago
Indeed, when making a tech decision it is important to think about how expensive it will be to change that decision later on. Avoiding premature optimization isn't an excuse to carelessly paint yourself into a performance corner.
gpderetta 6y ago
The full quote is much much more reasonable: "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%" Unfortunately everybody seems to forget about the last bit.
- vonmoltke 6y ago
  I think the first bit, that is also always dropped, is also important: "We should forget about small efficiencies". Removed from that context, it has morphed into an excuse by some people to not pay attention to efficiency at all, even when the potential gains are large for a relatively small amount of work.
  - mumblemumble 6y ago
    There's also a tendency to forget the impact of framing. One or two micro-optimizations may not add up to much. But a habit of, say, avoiding unnecessary object churn, might add up to a very large efficiency gain, a few microseconds at a time.
- commandlinefan 6y ago
  Especially considering the source: Knuth was a ruthless micro-optimizer, but his micro-optimizations actually made sense.
ChrisSD 6y ago
In my experience few people think that optimizations are to be avoided at all costs. Whereas it's very very common for people to try micro optimizing their code as they write it. Generally speaking it's much easier to profile and refactor well written but potentially slow code then it is to try to understand and untangle a mess of "optimizations" that are also a performance nightmare. Admittedly this may depend on the domain you're working in. And of course some people may take the advice to an extreme in the other direction but this is (IMHO) rarer and much easier to correct.
- gpderetta 6y ago
  I would say that the general trend these days is definitely in the other direction outside of some niches. Performance is a design issue and it is hard to do as an afterthought. In fact often microptimizations are the only optimizations you can do without changing your design.
  - ChrisSD 6y ago
    I'm certainly not against micro-optimizations. But they are very context sensitive and cannot be done without proper profiling of the whole program using representative workloads. I find people are often writing spaghetti code because they heard it's "faster". That said I would draw a distinction between implementation and design. The surface API needs to be well thought out before hand. But this should be done before writing any real code (exploratory code aside).
andrepd 6y ago
It's an incomplete quote, that mediocre programmers use as justification to be sloppy and lazy. The result is pulling in thousands of dependencies to make something that runs 100x slower and uses 100x more memory.
- cjonas 6y ago
  True, but if your evaluating the "success of software" by the code you have already missed the mark. IRL, the cost to build & maintain the software is almost always the determining factor in if the project is a success or not. Building off the shoulders of others is the only reason 99% of projects can be viable. value out > value in
cjonas 6y ago
Yes, but evil is a polynomial and has many roots, some of them are complex. – dan_waterworth (from comments of https://softwareengineering.stackexchange.com/questions/80084/is-premature-optimization-really-the-root-of-all-evil https://softwareengineering.stackexchange.com/questions/8008...)
Viliam1234 6y ago
> Sure, let's not prematurely optimize, but let's also not use that as an excuse to make horrible decisions or unforced errors also. That's similar to my reaction to "Unit testing won’t help you write good code." Of course it won't... but you are just using it as an excuse to not test you code at all.

tomxor 6y ago

I agree but for a slightly different reason: I think the notion is also highly subjectively applicable... some types of problems really do need a lot of forethought to make efficient - waiting until later can cause significant problems when decisions are hard to pivot away from or undo. An easy example is DB design, the cost neglecting these considerations upfront can be massive and sometimes impossible to migrate away from.

jamil7 6y ago
I agree with both of you. This quote is often used as a crutch on which to justify poor planning. Certain types of systems are very hard to "add" performance to as an afterthought and really need to be designed around it.

cellularmitosis 6y ago

Indeed, when making a tech decision it is important to think about how expensive it will be to change that decision later on. Avoiding premature optimization isn't an excuse to carelessly paint yourself into a performance corner.

gpderetta 6y ago

The full quote is much much more reasonable: "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%" Unfortunately everybody seems to forget about the last bit.

vonmoltke 6y ago
I think the first bit, that is also always dropped, is also important: "We should forget about small efficiencies". Removed from that context, it has morphed into an excuse by some people to not pay attention to efficiency at all, even when the potential gains are large for a relatively small amount of work.
- mumblemumble 6y ago
  There's also a tendency to forget the impact of framing. One or two micro-optimizations may not add up to much. But a habit of, say, avoiding unnecessary object churn, might add up to a very large efficiency gain, a few microseconds at a time.
commandlinefan 6y ago
Especially considering the source: Knuth was a ruthless micro-optimizer, but his micro-optimizations actually made sense.

ChrisSD 6y ago

In my experience few people think that optimizations are to be avoided at all costs. Whereas it's very very common for people to try micro optimizing their code as they write it. Generally speaking it's much easier to profile and refactor well written but potentially slow code then it is to try to understand and untangle a mess of "optimizations" that are also a performance nightmare. Admittedly this may depend on the domain you're working in. And of course some people may take the advice to an extreme in the other direction but this is (IMHO) rarer and much easier to correct.

gpderetta 6y ago
I would say that the general trend these days is definitely in the other direction outside of some niches. Performance is a design issue and it is hard to do as an afterthought. In fact often microptimizations are the only optimizations you can do without changing your design.
- ChrisSD 6y ago
  I'm certainly not against micro-optimizations. But they are very context sensitive and cannot be done without proper profiling of the whole program using representative workloads. I find people are often writing spaghetti code because they heard it's "faster". That said I would draw a distinction between implementation and design. The surface API needs to be well thought out before hand. But this should be done before writing any real code (exploratory code aside).

andrepd 6y ago

It's an incomplete quote, that mediocre programmers use as justification to be sloppy and lazy. The result is pulling in thousands of dependencies to make something that runs 100x slower and uses 100x more memory.

cjonas 6y ago
True, but if your evaluating the "success of software" by the code you have already missed the mark. IRL, the cost to build & maintain the software is almost always the determining factor in if the project is a success or not. Building off the shoulders of others is the only reason 99% of projects can be viable. value out > value in

cjonas 6y ago

Yes, but evil is a polynomial and has many roots, some of them are complex. – dan_waterworth (from comments of https://softwareengineering.stackexchange.com/questions/80084/is-premature-optimization-really-the-root-of-all-evil https://softwareengineering.stackexchange.com/questions/8008...)

Viliam1234 6y ago

> Sure, let's not prematurely optimize, but let's also not use that as an excuse to make horrible decisions or unforced errors also. That's similar to my reaction to "Unit testing won’t help you write good code." Of course it won't... but you are just using it as an excuse to not test you code at all.