No, but you usually don't know what will be the poorly performing part or in need of optimization, beyond the macro level. Don't check your brain at the door,

No, but you usually don't know what will be the poorly performing part or in need of optimization, beyond the macro level. Don't check your brain at the door, but don't overthink it too early. Someone else cites old systems with core decisions that are unchangeable because a data structure or algorithm is central to the entire codebase, as an example of "should have thought of performance earlier". My reaction to that was: why is the code structured in such a way that a particular data structure or algorithm is central to the entire edifice. I think the error the article makes is in describing later performance improvements as "accidental" and low hanging fruit, which is nonsense. If your code can't handle continual refactoring, including to realize significant performance gains, then you have a deeper problem than performance.