4 ms·

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 perspect

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 3y ago
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 3y ago
  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.
  - pdimitar 3y ago
    I agree and that's why I no longer want to work for startups or any company with "urgency" culture.
  - cultofmetatron 3y ago
    > 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.
- farhanhubble 3y ago
  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 3y ago
    Well that is a good way to go about it. Direct frontal assault against legacy problem indeed very rarely works.
- karmajunkie 3y ago
  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.
karmajunkie 3y ago
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.)

pdimitar 3y ago

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 3y ago
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.
- pdimitar 3y ago
  I agree and that's why I no longer want to work for startups or any company with "urgency" culture.
- cultofmetatron 3y ago
  > 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.
farhanhubble 3y ago
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 3y ago
  Well that is a good way to go about it. Direct frontal assault against legacy problem indeed very rarely works.
karmajunkie 3y ago
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.

karmajunkie 3y ago

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