Comment by benrutter
13 hours ago
I would argue that these:
- 'commitment to zero technical debt'
- 'design for performance early'
Will save you time and cost in designing, even in the relatively near term of a few months when you have to add new features etc.
There's obviously extremes of "get something out the door fast and broken then maybe neaten it up later" vs "refactor the entire codebase any time you think soemthing could be better", but I've seen more projects hit a wall due to leaning to far to the first than the second.
Either way, I definitely wouldn't call it "privileged" as if it isn't a practical engineering choice. That seems to judt frame things in a way where you're already assuming early design and commitment to refactoring is a bad idea.
Your argument hinges on getting the design right, upfront. That assumes uncertainty is low or non-existent.
Time spent, monetary cost, and uncertainty, are all practical concerns.
An engineering problem where you can ignore time spent, monetary cost, and uncertainty, is a privileged position. A very small number of engineering problems can have an engineering philosophy that makes no mention of these factors.