3 ms·

premature optimizations being bad is a tautology. optimizations that are not premature are a win though, and by making it standard to consider performance issu

premature optimizations being bad is a tautology. optimizations that are not premature are a win though, and by making it standard to consider performance issues from the outset, you and tour team get better at it, such that it doesn’t cost time to default to pretty efficient solutions. also some basic tech choices can often get you large constant factor wins without any downsides, like using a languages that are at least jitted rather than interpreted.

ZephyrBlu 6y ago
It's not a tautology, the parent comment clearly outlined some very good reasons for not prematurely optimizing things. - "At the end there are a lot of changes all the time to functionality and implementation and optimizations early get wasted very quickly" - "optimizations are opportunity losses at the beginning of a product"
- jtbayly 6y ago
  premature optimizations are by definition premature and that’s what makes it a tautology.
- ALittleLight 6y ago
  It is a tautology because the word "premature" means "before you have to" in this context. It's like saying "You don't need to do things before you need to need to do them." It's true by definition. The question is: which optimizations are premature and which aren't?
  - kaoD 6y ago
    I'd say it's not only a tautology, it's plain false. Cheap optimizations that are known to work (compiling in release mode, enabling HTTP cache in your web server, using a fast sorting algorithm on large arrays...) are good even if you don't need them right now.
    - cortesoft 6y ago
      That would mean they aren't premature
      - fendy3002 6y ago
        But the question still valid, which are and which aren't (premature)? For experts: avoiding n+1 query, using hash map rather than loop match, caching in memory, using smaller data type, all are standard optimization techinques. Now if junior doesn't implement them, are they didn't do required optimization, or do they do premature optimization if they did?
        mgkimsal 6y ago
        "premature" is in the eye of the beholder... (or implementer). I've cleaned up a lot of slow code over the last few years, and in most cases the 'fixes' are pretty simple. The pushback was typically along the lines of "YAGNI" and "premature optimization is the root of all evil" quotes, yet... yeah, you know what, we ARE "gonna need it", and adding a table index on a column you're querying on in a where clause isn't "premature". It's industry standard practice.
      - natchy 6y ago
        You don’t NEED them. They are premature. I don’t technically need to compile my app in release-mode as a small startup.
    - yipbub 6y ago
      > I'd say it's not only a tautology, it's plain false. And that, my friends, is a contradiction!
- hinkley 6y ago
  I think what the others are trying to say is that 'premature' is generally a label applied in hindsight. The preparations you made that turned out to make your life easier, the things you regret not doing, and the things that ended up being a total waste of time.

ZephyrBlu 6y ago

It's not a tautology, the parent comment clearly outlined some very good reasons for not prematurely optimizing things. - "At the end there are a lot of changes all the time to functionality and implementation and optimizations early get wasted very quickly" - "optimizations are opportunity losses at the beginning of a product"

jtbayly 6y ago
premature optimizations are by definition premature and that’s what makes it a tautology.
ALittleLight 6y ago
It is a tautology because the word "premature" means "before you have to" in this context. It's like saying "You don't need to do things before you need to need to do them." It's true by definition. The question is: which optimizations are premature and which aren't?
- kaoD 6y ago
  I'd say it's not only a tautology, it's plain false. Cheap optimizations that are known to work (compiling in release mode, enabling HTTP cache in your web server, using a fast sorting algorithm on large arrays...) are good even if you don't need them right now.
  - cortesoft 6y ago
    That would mean they aren't premature
    - fendy3002 6y ago
      But the question still valid, which are and which aren't (premature)? For experts: avoiding n+1 query, using hash map rather than loop match, caching in memory, using smaller data type, all are standard optimization techinques. Now if junior doesn't implement them, are they didn't do required optimization, or do they do premature optimization if they did?
      - mgkimsal 6y ago
        "premature" is in the eye of the beholder... (or implementer). I've cleaned up a lot of slow code over the last few years, and in most cases the 'fixes' are pretty simple. The pushback was typically along the lines of "YAGNI" and "premature optimization is the root of all evil" quotes, yet... yeah, you know what, we ARE "gonna need it", and adding a table index on a column you're querying on in a where clause isn't "premature". It's industry standard practice.
    - natchy 6y ago
      You don’t NEED them. They are premature. I don’t technically need to compile my app in release-mode as a small startup.
  - yipbub 6y ago
    > I'd say it's not only a tautology, it's plain false. And that, my friends, is a contradiction!
hinkley 6y ago
I think what the others are trying to say is that 'premature' is generally a label applied in hindsight. The preparations you made that turned out to make your life easier, the things you regret not doing, and the things that ended up being a total waste of time.