> we developers see a crazy mishmash of old requirements, dead code, unpaid technical debt, and ersatz business logic. We developers see a chance to make things better...

A rewrite to escape technical debt is akin to burning the house down because you are tired of paying the mortgage. A rewrite to get rid of dead code is akin to...I dunno, I cant even think of an analogy. But come on, just install ReSharper, select "find issues", delete all dead code. It will take less time than writing the blog post about the rewrite project.

Rule of thumb: The forces which have caused the previous project to accumulate technical debt are still in effect, so after the rewrite reaches feature parity you will probably have exactly the same amount of technical debt. If on the other hand you introduce measures which can control and reduce technical debt, why not apply them to the current project and save the rewrite?

And you are not going to get rid of the old requirements and ersatz business logic by rewriting, which is one of the good points the article make.

I would expect, based on both theoretical grounds and on past experience, that the rewrite will have more technical debt by the time it has reached feature parity.

Assuming your primary source of technical debt is all the little corners that get cut in order to meet a schedule, and assuming that the rewrite is being given far less time to get to a certain level of functionality than the original software took to get there, then one would expect the team to need to cut more corners to finish the rewrite. The code may be in a fancy new language, and it may be built on a more modern technology stack, but, in the mad rush to get a death march project done as quickly as possible, corners were cut.

If it feels otherwise, it may be because the project you're replacing was particularly messy. But probably it's because the design tradeoffs in the new system were made by yourself and your colleagues instead of that deranged pack of yahoos who were running things in the '00s.

That's a good point, but it considers only “internal” technical debt. Legacy platforms often have “external” technical debt that you are carrying, especially when they are unsupported by the original vendor. Rewrites are often motivated by the desire to escape this external technical debt, and end up trading a reduction in external technical debt for an increase in internal technical debt.

edit: Nvm, realize you're probably talking about something like migrating off of VB6, or ditching a mainframe.

You then end up with a hydra system, where you need to understand both legacy and rewrite systems, and their interactive, increasing the complexity even more!

Twice I was on a team that dove into a rewrite, spent a lot of time and came up with a new version that was pretty darn good. But both times the company ended up sticking with the old code and incrementally updating it as needed.

The only reason I would attempt a rewrite these days is to learn something new (e.g. new language) while working in a domain I was completely familiar with. It probably wouldn't even get deployed but would hopefully help me start on something truly new in a new language or using tooling I'd never used before.

But I guess at the end of the day there are valid reasons to do it and this seems like a decent start if you go that route.

Now do that with a bloated Rails code base. Or some other dynamic programing language. It's not even remotely that simple.

You sure that view isn't being rendered by something else? Are you sure that API endpoint -- which is using that weird decorator, which is using that legacy property, which is relying on that outdated library -- isn't being used by a client?

But if you have a large bloated code base in a dynamic language and no tests then you are definitely in deep trouble. A rewrite is not going to help you with that though, you will just end up the same place again.

Boss: Rushes in and shouts, "Our production systems all went down when you pushed the latest code. WTF DID YOU DO!"

Me: Oh, I just deleted all of the dead code that had no references. That's great right? @olavk said it was easy.

Boss: You're an idiot. We use an on demand assembly loading system! You just wiped out a quarter of our code base, so the rest is failing due those missing assemblies. FIX IT NOW!

"Why doesn't it do this? The old system did it."

Because when we were prioritizing stories, you said it wasn't important so we left it out.

"Oh! Well, I absolutely MUST have that!"

SMH.

Oh and of course with rewrites, you have the Architecture Astronauts designing the "one true system" that will be able to handle absolutely any CR that comes down the pipe. Um, sure, dude. Whatever.

For webapps you can even do this while changing languages (with a router that delegates some things to the old api and others to the new api).

Another approach that I would advice using is studying the usage pattern of the current code base (analyze the logs over a long timespan, and/or instrument the server), in order to avoid making assumptions about how the old codebase is used.

The idea is that an old project, albeit ridden with awkward technical debt, is a project that is currently delivering business value, and - as such - it is important to have ways in your toolbox to extract meaningful information from it, filtering out the bad parts

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

(Quis custodiet ipsos custodes?)