Often a feature pressure of "ship next week" is due to bad management and planning though. Often engineers already foresaw similar needs and were told no before. Then suddenly it is urgent.

I agree and that's why I no longer want to work for startups or any company with "urgency" culture.

> Often a feature pressure of "ship next week" is due to bad management and planning though

while thats usually true, it can also be a result of rapid customer feedback. what customers want might not be apparent till you put it in front of them. bad managers are one thing but if you're a startup, its more about responding to customer needs faster than the incumbent can.

Ultimately it is yet another optimization problem. You have fixed dev time, a budget and some deadlines. If possible, try rewriting a component and measure the effort and benefits. We had PoC with deep rooted data issues. We knew throwing it away would set us back by a year but it just kept getting uglier by the day. We added a thin data validation API around it which started catching a good chunk of the data issues and let us deploy the PoC. We're now rewriting a new core with built in data validation and tons of performance and reliability improvements.

Well that is a good way to go about it. Direct frontal assault against legacy problem indeed very rarely works.

my market was exactly this; tied to the start of the semester, if i missed shipping a feature my next shot at getting it used in production was months away. and basically if we missed the fall season it might as well have not even happened.