How many times do you think a developer or development team has looked at some legacy or technical debt laden software and exclaimed "this bollocks needs a complete rewrite!"? How many times do you think that same "complete rewrite" has lead to disaster taking three, four or more multiples of time than originally anticipated? I'd bet money on most. I've seen it happen. I've been in and lead teams where it's happened. It sucks for everyone involved.

Choosing to rewrite an application will inevitably feel like good progress to start with (at least after you've justified and got approval to rewrite "perfectly fine software" from those you need approval from). The original pain points that caused your egregious software development rage will be the first to go and everyone will rejoice. "Ding, dong, the witch is dead" they'll sing. "The bloody spaghetti monster is gone" the team will cheer. “Does anyone else hate their life?” the Senior Developer will sigh.

As time goes on, unless you're lucky enough to work for yourself (in which case, do what you want) or have an unlimited budget with no commitments, commercial leaders will grow tired of waiting. Pressure will build, corners will be cut, and mistakes, similar to those plaguing the original codebase you fought so gallantly to rewrite, will work their ugly facades into your source control repository once more.

When you finally deliver many moons later (in a big bang release as you decided to just "do it all at once") your expectations of jovial singing customers and development colleagues are instead met with an inevitable sleuth of technical debt that needs resolving, bugs you've introduced (by "fixing" previous issues) and the "oh shit" feeling that technical debt is an inevitability of all software worked on by multiple people that rewrites only temporarily hide.

It doesn't have to be this way.

What if I told you that you could reap all of the supposed benefits a rewrite gives you just by refactoring an existing codebase? What if I told you that by planning your refactor carefully you'd inevitably end up with a better understanding of why the original choices were made, how the original software is composed and how best to move forward with it? What if I told you I was starting to sound like Morpheus from The Matrix?

I imagine you'd think I'm mad, a servant to the bourgeois to protect their money or someone who hasn't seen proper spaghetti code before. I might be a bit of the first, you're right, but I've rewritten spaghetti monster codebases from scratch and found alternatives and I'd like to share them with you in this series of blog posts.