Comment by majormajor | Hacker News Reader

Comment by majormajor | Hacker News Reader

Parent Full thread

I've seen the first part of this story a lot.

Software product is delivering value, maintenance isn't needed much, people move on to other projects[0], people forget about it, then a couple of years later a change is needed.

But how would the first response in that "couple of years later" scenario be "throw away all that investment and start from scratch" instead of "dig into how it works"? That's not a long time, really.

[0] this is a good thing, IMO. If every project needs constant maintenance from its "owner" you as a company are going to rapidly run out of resources to do new things.

(There's a closely related thing, here, though, that as an individual or a low-to-medium level manager, keeping track of these risks and low-level maintenance areas is part of your job to find ways to keep it from ever turning into a disaster. At some point - 10 years, 15, 20... maybe the knowledge gap gets way too big for the current team - then get proactive.)

The real disaster is management. This thing was working perfectly, and therefore was ignored. Then it became a frantic crisis because nobody saw that some other change would break it.

And then they responded with an absence of reality. A two-week deadline that can't be moved? Um, no. Ever hear of reality? You might visit there sometime. It's a bit harsh on people with ridiculous demands, though, so adjust your attitude before you go.

And then, nobody can fix the existing one? You not only have the ridiculous demand, you rule out the only possible way of meeting it? What do you think is going to happen, the elves are going to work all night to magically create a solution?

This sounds like an epic management failure from start to finish.

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

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.

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.

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.

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

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.

Reply on news.ycombinator.com