[weliketocode]

There's already been tons of discussion here on HN about rewrites.

But, for the love of programming, please seriously consider this gradual rewrite/strangler pattern/whatever you want to call it over the often disastrous complete rewrite.

[rhacker]

Definitely agree. Unfortunately full-rewrites will always have some level of praise. Typically it starts with a POC, completely new tech stack, like for a new one starting today it will probably be a React/Node or something like that with GraphQL. Perhaps it is replacing a Java/JSP/JSF something-er-rather.

The POC will have the advantage of taking a small feature, and reproducing it, but working 10 times better, faster etc.. However, what is unfortunate is that often times the POC team will say, yeah this is about 80% of the way there, we still don't have X, Y and Z implemented. But that's where the rub is - it turns out that X, Y and Z are often always under estimated. After all, there is a reason they chose to exclude it from the POC.

Beyond that, the POC is just 1 feature usually. What about the other 80 screens. The POC team will then say, well if this took 3 weeks, then 80*3 (as a worst case) will be 4 year project - but the upshot is that it can be paralleled and done a lot quicker.

This is how I always hear it. So they put in a plan to do it, and things just start unravelling as you have 1) stakeholders slowing down work with getting existing functionality. 2) you still need to tackle the last 20% (which might really be 50%) 3) You will constantly drain resources for the next year or 2 from the ACTIVE product, and that battle will be ongoing.

If you use the strangler pattern, you will basically be making incremental releases that use the new technology AND the old at the same time. You don't have to replace the last 20% until it's absolutely a good idea. You're able to get the instant benefits to the screens/features you want out the door, and basically train up the existing team. There are no two teams competing, they are all working on the next short-term release.

[desc]

Indeed. I think the key point here is that even if the rewrite 'only' takes 4 years, how many new features have been added to the original codebase (maintained for 'continuity') in the meantime?

There's usually some expectation that the rewrite will make it 'quicker' to develop these new features so of course it will catch up. Eventually. After ten years of splitting the dev team to maintain two codebases. One of which has not produced any value in that time.

Alternatively the application featureset is frozen for the duration of the rewrite, and the company folds halfway through.

[pm90]

I imagine it depends on the situation.

Complete re-writes can sometimes help you elliminate a lot of technical debt and move faster if you do it right the second time. You can use different architectures, better tooling etc. So sometimes rewrites can be useful.

In other cases, your system might be doing just fine, and it needs parts of it re-written to be more scalable/efficient/whatever.

It always depends on the specific circumstance you're in. When deciding between the options, it makes a lot of sense to think through these things for a while and make sure you're doing it for the right reasons.

[dahart]

I don’t doubt it has happened somewhere, but I’ve never seen the mythical complete rewrite that was awesome and saved time and did it better the second time. Unless you’re talking about rather small projects of one or two people rewriting something in one month...

In three different large teams (~100 people) during my career, I have witnessed the other kind of rewrite. People forgot how many things were working right, and had started to focus only on the warts. They overestimated their ability to redo what they’d done before, and underestimated how long it would take. Why does anyone assume a multi-year project will go any faster the second time? You need a lot of evidence for that, and I’ve never seen any. In all cases, the rush to rewrite quickly caused people to cut corners and introduce new design mistakes, ultimately ending up with something that was only marginally better after a heavy cost of several years’ development. In all cases I’ve seen, the people in charge admitted regretting the decision to rewrite code and told me they wished they’d done it more piece-meal.

Just a data point, but I have to wonder how often a clean rewrite actually happens. I’m looking for the link now, but I remember reading on Wikipedia that it’s estimated that 30% of software globally is late and over budget. I suspect that rewrites are more affected by Planning Fallacy than the first time through, it’s easy to assume you can do better. https://en.m.wikipedia.org/wiki/Planning_fallacy

[james_s_tayler]

A big piece of enterprise software I've worked on did a full rewrite successfully. This was a long time before I joined, but the original product was written in Magik and apparently the only requirement was "make it work like magik" which I thought was pretty funny. It definitely was a success.

Though on the same product I came across a mildly hideous half-baked attempt at a UI framework re-write. I got the story on that and it was definitely one of the time-wasting regret stories.

Software is mostly just hard and expensive.

[juangacovas]

Yup. I can relate for a project in death march mode that was even already used by a first customer like a "beta" while development continued. A progressive refactor was the way to try to succeed. It did. But you need someone / a team willing to take the extra mile.