[lucideer]

> 1) There is almost never a case for a total ground up rewrite of your core product. Just don’t do it.

I've espoused this before, but I've come around to moderating my take on this.

"Almost never" is an exaggeration. I agree that they "almost never" work, but that's not the same as there being no case (there's a difference between "should not have done" and "should have done differently".

After many years of seeing both play out (rewrites and decided-not-to-rewrites) I'd edit this adage to: "there is almost never a case to rewrite yourself" (for the individual) or "there is almost never a case to get the same team to rewrite" (for management).

I'm not saying that engineers can't learn from their own mistakes but if you wrote the software & you think it needs a scratch rewrite rather than a refactor, you're unlikely to have learnt enough within that gap of time to make the rewrite significantly better than a refactor.

The other reason for failure outside of the original architect repeating their same mistakes 2nd time around is outsourcing the rewrite. Wholesale outsourcing is an unbelievably inefficient & failure-prone way to build in-house software.

[hinkley]

> you think it needs a scratch rewrite rather than a refactor, you're unlikely to have learnt enough within that gap of time to make the rewrite significantly better than a refactor.

Relentless Refactoring replaces the ship piece by piece while it's under way. If you are effective at it, you can effectively (both definitions) rewrite the entire app with few people being any the wiser.

If you are not good at decomposing a problem into digestible, coherent steps, then you are also lousy at Relentless Refactoring. If you can't decompose the problem, your top-down rewrite is statistically guaranteed to fail. Someone somewhere will get lucky, accidentally beating 1:4 odds over and over for 50 failure points, but that person will probably not be you.

The people who can Relentlessly Refactor don't need to ask for a top-down rewrite. They just get down to doing it. Therefore most of the people who ask for one are incapable of taking advantage of such permission.

Ultimately, the only people who ask for a top-down rewrite are the people who don't deserve it. They believe in do-overs instead of doing the hard work of removing obstacles. They believe in the Second System (without the attendant Syndrome), not in observing and adapting to new information as it becomes available. They have, in essence, trained themselves to continue to misbehave in the face of new wisdom. They will repeat that behavior during the rewrite.

[danrocks]

I enjoy Relentess Refactoring as much as the next guy, but one dimension here is that it is much easier to do in a headless app (or in the backend) than in an app with a major UI. At some point there must be a complete switch from the old UI to the new UI, and that step is extremely complex. It also invites a big rewrite, in an almost irresistible way - "since we'll change the UI, let's just do it from the ground up".

[hinkley]

The main lesson of the CI/CD era is that pain is information and ignoring it until later just makes things worse.

"Let's replace the whole UI at once" and "Let's replace the whole app at once" are bandaid-ripping activities, and the point of ripping off a bandaid is to get it over with before your pain receptors have a chance to tell you what an asshole you are right now. I'm sure most people have at least one experience, of their own or of someone they know, where ripping off the bandaid took a chunk of skin with it, possibly creating a bigger wound than the bandage originally covered.

[ska]

> unlikely to have learnt enough

There is an important caveat here - sometimes the original is rough not because you didn't know how to do it better, but because you were emphasizing speed and flexibility e.g. very early stage startup and you don't really understand the product here.

[see also, ship the prototype problem]

[lazyasciiart]

My moderated version: you are almost never going to do better at meeting the same goals with a full rewrite. Even when there is a good case for it, it is unlikely to work out.

[runlevel1]

A successful rewrite of a core product requires a mix of peers: Old blood, who know the wins and sins of the past, and new blood who'll bring a fresh perspective.