Don’t rewrite Your Application


News: Don’t rewrite Your Application

  1. Don’t rewrite Your Application (8 messages)

    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.

    Read the rest of this article at the following URL:

    Java Code Geeks: Don't rewrite Your Application

    Threaded Messages (8)

  2. Don’t rewrite Your Application[ Go to top ]

    I'm getting a bit confused about role of a person that article targets. Project sponsor? PM? Architect? Business analyst? Developer?

    It sounds as if it was a developer decision to rewrite application from scratch.


    That said, technical migration from legacy system to the new one can be a major PITA; people tend to think about system "new state" in isolation, forgetting the need to switch over in a controlled and undoable fashion with minimal downtime.

  3. Rewrite decided on several parameters[ Go to top ]

    Rewriting an Application is decided based on several parameters

    - S/W the application is using

    - H/W platform the application is hosted on EOL

    - Changing Enterprise technology landscape

    - Chaning business needs


  4. Sometimes it's the only way[ Go to top ]

    What the article fails to explore is that most of the (valid) rewrites of systems or parts of systems are based on incorrect arcitectural decisions taken early on in the original development project. While being neither evil or stupid, people sometimes make decisions that turn out to be incorrect. You select plattforms or products based on incorrect assumptions or flawed or incomplete fasibility analysis. And, as the future is so hard to predict, sometimes requirements evolve so far beyond the original scope that the architecture simply can't accomodate them.

    Just saying "don't rewrite" and giving exceptions like "you can rewrite if you were going to rewrite anyway" is oversimplifying the problem greatly. As with everything else, it's a balance between cost, timing, benefit and ROI. It's not easy, but I've seen instances of lost opportunities from being overly defensive just as I've seen instances of wasteful efforts by being overly optimistic. But a senior architect worth his salt must be able to sit down with his or her stakeholders and do these determinations, not going on gut-feeling or "conventional wisdom" because every sitation is unique.

  5. Don’t rewrite Your Application[ Go to top ]

    personally I had several good experiences in taking the rewrite approach. Sure, in two years your code won't be so nice as it was at the beginning, but it is absolutely not the reason to throw away this option. If you stuck with the legacy code, it will look much more ugly in further two years of permanent bug fixing. Sometimes you should rewrite, just like you should periodically refactor your code.

  6. Fourth reason[ Go to top ]

    There's actually a fourth reason to refactor rather than rewrite: the legacy codebase almost always contains hidden functionality (features) that can't be found in the documentation. Doing a rewrite will loose these features and will be difficult to get them back. Doing a gradual refactoring may cause some of these features to be broken, but they will be found when the product goes to production (I recommend Agile development, with a short release cycle).

    Refactoring then has the added benefit, that you can compare one version against the previous. Thereby (hopefully) quickly finding the broken code. When you've done a rewrite, there's nothing to compare. The codebases are completely different. The rewrite is like throwing away intellectual property.

  7. tests[ Go to top ]

    And don't forget that having good test coverage with regression tests is very helpful with both refactoring and rewriting. If your legacy code is not good for unit tests then functional (black box) tests may help


  8. It depends[ Go to top ]

    It needs to be evaulated on a case by case basis. Re-write/Re-factor decision is really based on business needs, architecural needs, ROI, level of effort estimates etc. But as a good coding practice, code needs to be re-factored as often as possible to make it easy to maintain, support and allow for future functional/technical/architectural enhacements.
  9. Don’t rewrite Your Application[ Go to top ]

    The standard link to Joel's "Things You Should Never Do" is missing:

    Things You Should Never Do