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.

Related Articles :
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply

six × 9 =

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books