[farhanhubble]

That's micro-shortsightedness. Lots of tools even OS utilities are being rewritten in a "better" language. It could be quite beneficial from a business perspective too if you're spending more time fixing issues than addressing new requirements.

[pdimitar]

That really depends though. Part of the time you are right but there are legitimate businesses settings where not shipping by the end of next week can mean missing out on much-needed $50K or so revenue.

[zelphirkalt]

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.

[cultofmetatron]

> 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.

[pdimitar]

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

[karmajunkie]

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.

[farhanhubble]

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.

[pdimitar]

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

[karmajunkie]

it’s kind of a matter of scope. you’ve got a team, at least a couple developers, rewriting a microservice that really needs an overhaul for performance? go for it.

you’re a solo developer rewriting the fundamental application your company sells and depends on for revenue? yeah, maybe not so much. (actually there’s no maybe about it. don’t do this.)