5 ms·

> But how would the first response be "throw away all that investment and start from scratch" instead of "dig into how it works"? Because start from scratch is

> But how would the first response be "throw away all that investment and start from scratch" instead of "dig into how it works"? Because start from scratch is more predictable ("estimable") than "dig into how it works". "Dig into how it works" is better in the long run, but will take longer. All software management is laser focused on speed and predictability rather than long-term quality.

majormajor 4y ago
This is exactly the case where I think starting from scratch is the most difficult to estimate. This thing we need to update is a mystery-box, right? You don't know the code. You don't know all its edge cases. Tons of potential bugs could be introduced (or re-introduced) if you change it in the wrong way. Replace-from-scratch has all the same risk of getting things wrong because of that lack of knowledge and a bunch more new-code-writing on top of it. Estimating new development often fails; estimating it in the face of business requirement uncertainty is even worse.
- WorldMaker 4y ago
  Can you quantify that to the management in that case? To certain styles of management focused on "always building new products" to guarantee their worth/value, they absolutely will get blinders on and believe "new products are easy and more predictable than maintenance of old products". Those blinders are hard to take off once they get into that sort of pattern. All of their processes are built around "new products". That starts to be the hammer that wants to dismantle old products because they don't do maintenance (that's someone else's problem) but they surely know how to build new products. They are the build new products group, that's what believe they do. Building new products is exciting and they can be passionate about it. I also think that's generally the wrong way to work and does plenty of harm and creates a lot of unnecessary stress on development teams caught in those cycles. But I've certainly seen plenty of management teams that do work that way in the real world and maybe don't question it enough.
seti0Cha 4y ago
Two terms you may want to refresh your memory on: second system syndrome and Chesterton's fence. I've never seen a rewrite come in remotely on time, and I've seen quite a few fail altogether. Often what happens is, in trying to solve the problem again, the developers come to understand the original system, which already works. It becomes impossible to articulate tangible benefits for the rewrite and it gets shelved.
mfuzzey 4y ago
"Dig into how it works" may take longer than rewriting or it may not. And the rewrite may (and often does) run into unexpected difficulties too. I think it's a mistake to make the "fix the old" or "rewrite from scratch" decision up front from a position of high uncertainty about the old system. I'd go with a strategy of starting a timeboxed exploration of the old system with the objective of understanding it better, hopefully well enough to have a reasonable idea of what it will take to fix it. Then make the decision from a better informed position. Yes sometimes the decision may still be to rewrite because you now know that the old system will be excessively hard to change but in many cases you may find out that the old system wasn't as bad as expected.
yamtaddle 4y ago
Rescuing everyone with a shiny new system also takes more resources and looks (as you kinda note, too) a lot more like a real project, so product managers and project managers and various other managers can get comfortably involved and do their thing, with plenty of people to manage (= more prestige) and new UI to show off in powerpoints (= more prestige, doesn't even matter if it functions worse than the old one) and ordinary, regular development milestones. Learning the old system enough to keep working with it, meanwhile, looks a lot like a couple developers staring at screens for months without results that look impressive to anyone who matters (as far as granting rewards goes) and with very uneven progress. Plus they've gotta be pretty good, experienced developers (so, likely expensive), or the risk of breaking shit as they begin trying to change the system, goes up a ton.

majormajor 4y ago

This is exactly the case where I think starting from scratch is the most difficult to estimate. This thing we need to update is a mystery-box, right? You don't know the code. You don't know all its edge cases. Tons of potential bugs could be introduced (or re-introduced) if you change it in the wrong way. Replace-from-scratch has all the same risk of getting things wrong because of that lack of knowledge and a bunch more new-code-writing on top of it. Estimating new development often fails; estimating it in the face of business requirement uncertainty is even worse.

WorldMaker 4y ago
Can you quantify that to the management in that case? To certain styles of management focused on "always building new products" to guarantee their worth/value, they absolutely will get blinders on and believe "new products are easy and more predictable than maintenance of old products". Those blinders are hard to take off once they get into that sort of pattern. All of their processes are built around "new products". That starts to be the hammer that wants to dismantle old products because they don't do maintenance (that's someone else's problem) but they surely know how to build new products. They are the build new products group, that's what believe they do. Building new products is exciting and they can be passionate about it. I also think that's generally the wrong way to work and does plenty of harm and creates a lot of unnecessary stress on development teams caught in those cycles. But I've certainly seen plenty of management teams that do work that way in the real world and maybe don't question it enough.

seti0Cha 4y ago

Two terms you may want to refresh your memory on: second system syndrome and Chesterton's fence. I've never seen a rewrite come in remotely on time, and I've seen quite a few fail altogether. Often what happens is, in trying to solve the problem again, the developers come to understand the original system, which already works. It becomes impossible to articulate tangible benefits for the rewrite and it gets shelved.

mfuzzey 4y ago

"Dig into how it works" may take longer than rewriting or it may not. And the rewrite may (and often does) run into unexpected difficulties too. I think it's a mistake to make the "fix the old" or "rewrite from scratch" decision up front from a position of high uncertainty about the old system. I'd go with a strategy of starting a timeboxed exploration of the old system with the objective of understanding it better, hopefully well enough to have a reasonable idea of what it will take to fix it. Then make the decision from a better informed position. Yes sometimes the decision may still be to rewrite because you now know that the old system will be excessively hard to change but in many cases you may find out that the old system wasn't as bad as expected.

yamtaddle 4y ago

Rescuing everyone with a shiny new system also takes more resources and looks (as you kinda note, too) a lot more like a real project, so product managers and project managers and various other managers can get comfortably involved and do their thing, with plenty of people to manage (= more prestige) and new UI to show off in powerpoints (= more prestige, doesn't even matter if it functions worse than the old one) and ordinary, regular development milestones. Learning the old system enough to keep working with it, meanwhile, looks a lot like a couple developers staring at screens for months without results that look impressive to anyone who matters (as far as granting rewards goes) and with very uneven progress. Plus they've gotta be pretty good, experienced developers (so, likely expensive), or the risk of breaking shit as they begin trying to change the system, goes up a ton.