Often I hear the sentiment ...
"Why worry about performance, write slow code, get your product to market ... don't worry about performance. You can sort that out later"
The culmination of this sentiment is:
"... premature optimization is the root of all evil ... #winning"
I was wondering, does anybody have a good retort to this one liner. Ideally an equally strong one liner that encompasses the reverse of this sentiment?
The point of that statement is not to imply that you should write slow code or sloppy code just to get it done quickly, and someone who states it as you did "write slow code, get your product to market", is greatly misinterpreting it.
It's point is that you should not spend time micro-optimizing code that has not yet proven to be problematic.
The implication is that you aim to build a complete, well thought-out, and functioning application before squeezing out extra CPU cycles.
So I haven't answered your question. I offer no retort, other than to correct them about the purpose of avoiding premature micro-optimization.
Addendum As I was cooking breakfast, I thought of a better summation:
When developing new code, the time you might spend micro-optimizing every for-loop is much better spent thinking about higher-level organization and integration. That time spent on organization & integration at the earlier stages pays dividends when the time comes that you actually do need to optimize a component; a localized refactoring or optimization is likely then to require less rewriting and of surrounding code.Tweet