To view parent comment, click here.
To read all comments associated with this story, please click here.
The way I interpret this "early optimization is the root of all evil" quote, it reads that one should not prioritize optimization above more important concerns the first time which code is written.
If there's no compromise to make, then I agree that it's possible to optimize right from the first time, or even at the design stage.
But what I was trying to point out is that it's relatively easy to optimize well-written code, as soon as it is sufficiently flexible by design (i.e. we can optimize without breaking function calls or thing like that). So one should not worry too much about optimization too early.
Good cement dries slowly, so to speak.
Edited 2011-01-30 10:00 UTC
Once the whole thing works, the "cement" has already begun to dry, so to speak.
You shouldn't do *anything* up-front except writing a prototype to get feedback. Then you'll see what you did wrong, including performance issues. If "drying cement" keeps you from fixing problems, your project will have much more serious issues than performance.
"You shouldn't do *anything* up-front except writing a prototype to get feedback. Then you'll see what you did wrong, including performance issues."
I don't think anybody here was referring to the prototype. Never the less, if your prototype is functional enough that it can be used for performance analysis, then it seems to me that you've already put in a significant investment, no?
In any case, if you believe in building a separate prototype and using that for performance analysis, then you really ought to agree with me that planning for an efficient design up front is important since that's essentially what a prototype is. This way you can analyze what works and performs well BEFORE you get too far into development of the production code.
"If 'drying cement' keeps you from fixing problems, your project will have much more serious issues than performance."
What is that supposed to mean?
I think I've made a strong case on why planning for efficiency early on is important, sometimes more so than optimizing later on. It doesn't really matter if I'm right or not because it flies against the tide of authoritative people who say the exact opposite. In the end, no matter how much merit my argument actually holds, I know that I've lost.





Member since:
2011-01-28
"The first time code is written, the primary priority of a developer should not be speed, but cleanness, maintainability, and getting it to work."
I don't disagree with the order of priorities here. But I do believe efficiency should have a larger role up front than your suggesting.
Once the whole thing works, the "cement" has already begun to dry, so to speak.