Don’t rewrite Your Application

When stuck with a legacy code base you’ll hear the claim “We’ll have to rewrite this from scratch in order to fix it!” It sounds promising. You start with a clean slate. You can do all the good stuff without all the mistakes. The only problem: It doesn’t work. Here is why.

1. What every you might think of the code base and the developers that created it: They weren’t stupid nor evil. So chances are the results of your work will look just as ugly in two years from now.
2. You don’t know the requirements: Part of the reason legacy code bases are ugly is that requirements change. There is no reason for you to assume this won’t stop.So chances are the results of your work will look just as ugly in two years from now.
3. You don’t have the time: As long as the rewrite isn’t done, you’ll need to maintain and probably evolve the current application. If it is of any importance, you can’t ignore it for the months to come. If you can you should do so without wasting your time with a rewrite.

Instead of rewriting the application refactor it. Learn to properly estimate the effort needed for implementing new features in a clean way. Add some time to make the code immediately around that new feature a little cleaner as well. Use that as estimate. This way the application will become a little cleaner with every update. Nobody needs to spend a huge lump of money without a good chance on a reasonable ROI. Instead you spend a little money and get what you paid for. The interesting effect of this approach is: The part of the code changed often will become cleaner fast. And nobody should be concerned to much with code that doesn’t change anyway.

If you can’t implement new features in a clean way I claim: You aren’t really able to implement the whole application in a clean way from scratch either.

There are only a few cases in which I’m willing to believe a rewrite is benefical:

1. Change of basis technology: Is the legacy code written in Cobol and you will loose the last machine running that? Is it a rich client and it must become an internet application? You might not have a choice.
2. Change of scope: Is 80% of code not needed anymore due to some changes in requirements? And you have to implement just as much for new features? You are doing a rewrite anyway.
3. Tiny application: When the rewrite is done end of the week, I guess it is Ok to do it. But I still recommend doing it using refactorings. It will teach you the technique for the next larger legacy application.
4. Somebody is willing to pay for the rewrite, but not for the effort needed to keep new code clean. It sounds extremely stupid to me, but I was told this happens.

Reference: Don’t rewrite Your Application from our JCG partner Jens Schauder at the Schauderhaft blog.

• Those evil frameworks and their complexity
• How many bugs do you have in your code?
• The top 9+7 things every programmer or architect should know
• Top 25 Most Dangerous Software Errors – 2011
• 9 Tips on Surviving the Wild West Development Process