3 ms·

Don't optimize your software prematurely

11 points by titpetric 13y ago

recentdarkness 13y ago
Alone the title reminds me of this: "Premature optimization is the root of all evil (or at least most of it) in programming." Source: Computer Programming as an Art (1974) p. 671
- titpetric 13y ago
  Pretty sure you are correct. The "quote" was paraphrased from my poor memory. Also from what I read, the book series is, even today, very informative and relevant. I am however disappointed how much damage this quote is doing outside of a proper context. "In practice, it is often necessary to keep performance goals in mind when first designing software, but the programmer balances the goals of design and optimization." ^^ This. I am ashamed when the original quote is being used to basically advocate "write un-optimized code and we'll buy hardware, which is cheaper than development time". I do realize that wasn't the case back when the books were written (hardware was hella expensive), but today this is just encouraging bad form in developers, many times their go-to reaction is "let's add more ram".
  - serge2k 13y ago
    Yup. Instead of discouraging the idea of writing unmaintainable code that is faster in an area that may not even be a bottleneck we get people who use that quote to excuse writing terrible code. Good design is not premature optimization.
- mantrax4 13y ago
  The quote actually goes back much earlier, to the days where writing a program meant writing machine code routines. And it's also highly misunderstood, because it's used as a mantra, out of context. Good development is not mantra-driven.
Fa773NM0nK 13y ago
I like to think that our programming philosophies aren't carved in stone. (KISS, DRY, YAGNI, etc.) To quote Captain Barbossa: ... the code is more what you'd call "guidelines" than actual rules. Also, "A foolish consistency is the hobgoblin of little minds"
- titpetric 13y ago
  I like to think so to - guidelines are basically what best practices are. And behind every best practice there's a programmer who at one point failed and fixed their mistake. If you buy more ram/cpu/disk, are you allowing them to fail, or are you just "patching" the problem yourself?

11 points by titpetric 13y ago

Alone the title reminds me of this: "Premature optimization is the root of all evil (or at least most of it) in programming." Source: Computer Programming as an Art (1974) p. 671

titpetric 13y ago
Pretty sure you are correct. The "quote" was paraphrased from my poor memory. Also from what I read, the book series is, even today, very informative and relevant. I am however disappointed how much damage this quote is doing outside of a proper context. "In practice, it is often necessary to keep performance goals in mind when first designing software, but the programmer balances the goals of design and optimization." ^^ This. I am ashamed when the original quote is being used to basically advocate "write un-optimized code and we'll buy hardware, which is cheaper than development time". I do realize that wasn't the case back when the books were written (hardware was hella expensive), but today this is just encouraging bad form in developers, many times their go-to reaction is "let's add more ram".
- serge2k 13y ago
  Yup. Instead of discouraging the idea of writing unmaintainable code that is faster in an area that may not even be a bottleneck we get people who use that quote to excuse writing terrible code. Good design is not premature optimization.
mantrax4 13y ago
The quote actually goes back much earlier, to the days where writing a program meant writing machine code routines. And it's also highly misunderstood, because it's used as a mantra, out of context. Good development is not mantra-driven.

Fa773NM0nK 13y ago

I like to think that our programming philosophies aren't carved in stone. (KISS, DRY, YAGNI, etc.) To quote Captain Barbossa: ... the code is more what you'd call "guidelines" than actual rules. Also, "A foolish consistency is the hobgoblin of little minds"

titpetric 13y ago
I like to think so to - guidelines are basically what best practices are. And behind every best practice there's a programmer who at one point failed and fixed their mistake. If you buy more ram/cpu/disk, are you allowing them to fail, or are you just "patching" the problem yourself?