Hacker News Reader

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

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.

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

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.

By "external" technical debt, do you mean crufty old 3rd-party components? Why not deal with those by just swapping out that one component?

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

I agree, and migrating from a dead end platform is one the few legitimate justifications for a full rewrite.

100% this. I've also seen a lot of cases where the rewrite is partial, and integrated with the legacy system to preserve end to end functionality, as they don't have enough time to do the full feature set, migrate all the data from the legacy system etc.

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!

Yeah, I have to say I was fully expecting step one to be "Sit down and think long and hard about why you are contemplating a rewrite. Is it really worth it?"

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.

Based on the ReSharper reference you've got tunnel vision for .Net apps.

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?

I mentioned ReSharper because the article is about a rewrite of a .net project.

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.

You would need 100% test coverage to be certain you're not going to break something, though. And that's generally unheard of.

delete all dead code.

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!

What, no integration testing?

And the dynamically loaded code could use a UsedImplicitly annotation

Sorry about that! But actually ReSharper have attributes to annotate dynamically loaded interfaces, so they don't get flagged as unused.

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

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