
A Five-Step Process for Planning a Rewrite of a Legacy Project - joeyespo
https://exceptionnotfound.net/a-five-step-process-for-planning-a-rewrite-of-a-legacy-project/
======
olavk
Some good points if you _have_ to do a rewrite, but:

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

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

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

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

------
rawfan
If it is a complex project, I usually would avoid a rewrite. There is good
literature on how to approach modernization of legacy applications step-by-
step. Read it, apply it. In the end the modernization is a re-write. It's just
one where you don't loose features.

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

------
muxator
I always found an iterative refactoring of the old code a better engineering
approach: small changes that do not modify the external behavior, but end up
extracting a better design. Martin Fowler expressed it clearly in a 1999 book:
"Refactoring: Improving the Design of Existing Code"

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

------
walrus1066
This is the most pertinent article on rewrites for me. 17 years old but very
relevant.

[https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
Zanni
Indeed. I expected an article on rewriting software to at least cite this, if
not quote from it.

------
eej71
Perhaps I'm being rude, but it seems like it was pretty small if it was
completed within a year's time. Wish there were more details about the actual
size of what was rewritten.

------
gerbilly
Yes, but who will rewrite the rewritten code?

(Quis custodiet ipsos custodes?)

