Photoquarium Blog

Sometimes you encounter things at just the right time. This article is one of those things at the right time. Please read this article if you have ever had to deal with legacy code and muttered under you breath, “Can’t we just scrap this crap and start over”, when trying to fix an issue. Below is my spin on it for the situation I am in.

Fix it or rewrite it

We have all had to face this dilemma at one point in out development careers, do we take that old crappy broken piece of software that we have been patching and re-patching and scrap it for a brand spanking new rewrite that will solve all of out issues, or do we take the time to properly fix what we have and evolve it into the application that we wished it was.

I have been struggling with this with one of the applications that I have maintained for years, is it worthy of scrapping for a full rewrite or should we just take the time and effort to fix it once and for all. There is no need to say its name we all know what it is (plus I wouldn’t want it to find out I am bad mouthing it, more things might go wrong).

I see both sides of the coin here:

On the Heads Side:

The developer in me wants to scrap it and be able to work on that pretty, clean, all mine application that will not have all the headaches and stigma that the original application has. I will be able to design it from the ground up and it will be prefect. The perfection of green field projects:

In a green field you don’t have to deal with the mess that’s accumulated over the years. In a green field you can be clean. In a green field you can build the perfect system. All would be well if only we could start over with a green field.

We will be able to use that new technology, remove some of the constraints that are ingrained in the old venison learn from all our pains and make this new fancy 2.0 version that we all dream of.

On the Tails Side:

But wait, what about all the years of evolving that the original application had gone through, how do I get that in this green field application? Can I extract all the correct requirements and business logic that is all ready included? What about new requirements, do I stop maintaining the old application and only add these new requirements to version 2.0.

Remember Xeno’s Paradox? Achilles and a tortoise are in a race. The tortoise has a head start. Every time Achilles gets to where the tortoise was, the tortoise has moved to a new point ahead of Achilles. Therefore Achilles can never catch the tortoise.

Fortunately the law of limits allows us to escape this paradox in a mathematical sense. But in software the paradox sill holds. The Tiger Team can never catch up to the old system. Every time they get to where the old system was, the old system has added new features

I don’t know what part of me this is coming from but I do think that the best solution would be to take this ailing, almost dying application and revive it, give it the million dollar man makeover. We can make it better. I know we can. This might be a little bit of my ego saying I can fix anything but more realistically there is to much inherent knowledge inside the existing application that take years to duplicate, heck it took us years to get it in there in the first place.

Taking the existing structure of the application and improving upon piece by piece will help keep this knowledge in the system but as we slowly evolve the existing application. We can address the most painful points first and take it one step at a time. This doesn’t have to mean that we are going to stop maintaining and fixing issues as they arise, we just have to make some due diligence and fix them properly with an eye to the future. This may mean no more 1-2 day turn around time, instead more like 1-2 week turn around time (or longer depending on the underlying issue). But over time we will see a new and improved application break free from the cocoon of crappy code.

It may be easier in the short term to scrap the old application but unless we face the reasons why the old application became that way we are destine to repeat them. If we step up and face the fact that we contributed to this crap, promise to fix it, and deal with the decisions we have made we can learn and evolve just as our application has to and not repeat history be it on new projects or on the same one.

Now I could just keep going on and on about this but instead here is a few more articles from people that you might respect a bit more (or might not) that echo my opinion:

Things You Should Never Do, Part I – Joel Spolsky

The Big Rewrite Series – Chad Folwer