Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

Don't Rewrite Your Application

  • submit to reddit

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 …



Published at DZone with permission of Jens Schauder, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Jose Maria Arranz replied on Wed, 2011/09/21 - 2:58am

I think "refactoring expert" should be a new kind of job **for very experienced developers** used to manage many thousands of lines of code.

The legacy code, in spite of it has become crap, has a lot of value because the business rules are there, the work of a "refactoring expert" is "just" to bring this mess with tons of unnecessary coupling, plain architecture (no OOP), and plenty of copy pastes to a more S.O.L.I.D. state.

In this type of job the help of a strong typed language like Java is invaluable because basically the end application after refactoring works the same but with less bugs and with an architecture more ready to evolve and add new features.

When I see the modern trendy of dynamic languages I think for myself "what a nightmare for refactoring", I've had recently the experience of deep refactoring of a Java/Groovy application and the Java part what a pleasure, the Groovy part was hard because of the lack of a compiler, fortunately the Groovy part was small. Tests can help, for refactoring tests are useful but not essential and in a deep refactoring you must also refactor the tests and again a static language and a compiler are invaluable.

François Eric replied on Wed, 2011/09/21 - 7:58am

I think all the points you make are valid. Where I disagree though is on the frequency of the cases to rewrite. From my experience, the rewrite discussions are often instigated because:

A) They had their application made by a junior developer that had no idea about architectural design and the maintenance of their current application is excessively expensive and has been for a few years and are looking to know if they can save in the long run.

B) Their application is in an old technology (i.e. FOXPRO, Cobol, etc.) and need to make major changes

C) They want to switch providers.

C is obviously not a good reason itself to rewrite (unless you can't have a provider to accept the challenge) but A and B often are.

Rewrites are really hard. Someone once told me that 80% of rewrites are failures. I don't know where he got his statistics but I tend to believe him... This being said, I have been part of quite a few successful rewrites and I have to say that even though they can be hard and non-profitable on a short term basis, for my particular clients, they were very profitable on a long term basis.

So what's my point? I think you are right of saying that we should think carefully before rewriting but I think that more and more companies are stuck with legacy tehcnologies and are paying astronomical costs to maintain them (let alone build new functionnalities). These companies should at least investigate the rewrite option.

Lund Wolfe replied on Sat, 2011/09/24 - 4:54am

Agree that rewrites are high risk and often fail. Agree also that a rewrite is desired because of less skilled original developers with no design sense, and further it was never refactored early on or by later enhancement developers with more skills or more knowledge of the application requirements taken as a whole.

Requirements is the hardest part of development. Just narrowing down the requirements for a single enhancement can be the most head scratching and time consuming part of development. Trying to reverse-engineer the requirements from a big ball of mud, poorly designed, unreadable code base may not be impossible but it will be frustrating and time consuming and it will be risky.

Some features/fixes will require a redesign and can't be thrown in after the fact without the code looking like an ugly hack and becoming even more unmaintainable. That doesn't mean it can't be rewritten, but if it now takes an expert developer to fix and enhancement without regression and degeneration of application quality then it will take a "refactoring expert" or better to do the redesign successfully. Some developers are better at new development and some are better at maintenance, but new development is significantly more difficult (to do well) than maintenance where you mostly just code to the existing pattern. Frequently we get away with ill-conceived designs because the project is new and the requirements are minimal. The design is proven in time by how successfully it flexes and scales with code growth and requirements complexity. A weak design becomes unintentional extreme technical debt.

Many applications should probably get a rewrite but the likelihood of finding developers of sufficient caliber to prevent failure is probably pretty poor. Refactoring a little at a time comes with a much lower risk and is much more doable by a competent programmer but the application will almost certainly not be in the same class as a new well designed rewrite. You can eat an elephant one bite at a time, but I'd rather not.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.