Don’t Fear The Rewrite

by on April 8, 2013 8:44 am

Over the past dozen years, I’ve been involved in half a dozen engagements where my role was to lead an effort to rewrite a particular application. The applications were each very different, but there were quite a few similarities. This article gives my top ten tips for how to successfully rewrite an application.

Before jumping in, you should ask yourself why are application rewrites so common? In many cases, the application is working (at least, mostly) and it costs money to take existing, working functionality and write it all over again.

The main reason I hear is maintainability. Applications become too costly to maintain when you can answer “yes” to the following:

  • Is the application built on technology that requires outdated skills or tools?
  • Is the only way to know the application’s capabilities to “try it and see” or to get under the hood and look at the code?
  • Is there major concern that minor fixes may cause major breaks in unrelated parts of the application?
  • Is the application resistant to scalability?
  • Is it hard to add small enhancements, never mind making major improvements?

Any one of these reasons can be used to justify a rewrite, but when you answer “yes” to all of them, it should be an easy task to justify the costs associated with a rewrite.

The Rewrite

Once you’ve successfully argued your case and gotten the funding to move forward, this is when the fear sets in. Looking at the existing application at a high level, you have a good idea of what you want to build, but how do you ensure you get the detailed requirements right? How are you going to be sure that this time you get it right? You will want to make sure you choose the right technology and that you don’t build an application that is too brittle and inflexible for future enhancements? What will be different this time that makes this implementation more maintainable?

These are all good questions, but relax; you have a very good chance of being successful. Since most applications being rewritten were initially designed a decade or more ago, you need to be reminded that a lot has changed in that time. Even though we thought we had all the answers back then, we’ve come a long way and learned a lot in that time. All areas of technology have improved. Databases can handle many more transactions; storage is cheaper; there are multi-tenant implementations and don’t forget the cloud. I prefer to write applications using Java, and a dozen years ago it was in its infancy where frameworks like Spring were non-existent.

Processes and methodologies have come a long way also. Waterfall process has been used to successfully implement many important applications, but a quicker, more agile way of developing applications is vital to success in today’s world. Iterative development took a large step in the right direction, but now the Agile Development Methodology has made teams more productive and projects more likely to succeed (or fail) fast. While object-oriented development has been around for decades, the promises for reuse and maintainability are currently being proven every day.

So, once you conquer your fears and are ready to jump in, here are my top ten tips for things to remember as you consider rewriting your applications:

1. Design for Reusability / Be Object-Oriented

Hopefully by now all software development organizations know how to write good object-oriented code. For your application to be object-oriented means that you write classes of code that model your real world business domain. Your design leads must have a talent for recognizing where responsibilities lie and what one place in your system they should be coded. Avoid having multiple copies of the same code in multiple places as this becomes one of the huge maintenance pot-holes of the future.

2. Use a Layered Architecture

Which User Interface framework are you using? Which Persistence framework are you using? While these decisions are important, don’t tie yourself down. Layer your application so that you isolate the business domain, data persistence, services/business rules, and user interface. This layering will allow you to more easily change out a layer if necessary, while also enabling reuse and integration by other applications.

3. Choose your technology wisely

For some organizations, this is an easy step because technology choices are made by overarching organizations. For others, however, this becomes one of the more likely areas to stall. You can easily spend months reading about, evaluating, and hopefully prototyping different frameworks and tools. And just when you are about to commit, someone tells you a horror story about the one you’ve chosen. My advice is not to choose the latest and greatest of everything. Go with proven technologies that are still growing and evolving and especially look at what skills developers are investing their time in. Not all teams can ramp up quickly enough to implement a new set of frameworks on their own. If you have to hire or contract for additional skills, make sure the technology is one that allows your team to grow into it.

4. Find a leader that has done this before

Existing teams often have strong technical leaders that have been entrenched in the existing implementation and technology and who hold the keys to that embedded knowledge about the application. These leaders will be very important for the rewrite, but you also need someone who knows how to lead a rewrite effort. Too many times the existing resources are convinced that it will be too hard to rewrite the application and you will need someone with a fresh perspective who knows how to take your 4-ton legacy application and turn it into a svelte 500 pound dynamo.

5. Be Agile / Keep teams small

I am a huge fan of the Agile Development Methodology, not because it is the process of the day, but because it lets everyone on the team, including managers, developers, testers and technical writers focus on what gets the job done right.

One term you will hear associated with Agile Development is “fail fast.” This doesn’t mean you have less chance for success with Agile, it means that if you have made a choice that is not going to work for you, you will find this out sooner rather than later. Also, Agile is scalable to your team needs. If this rewrite will take 50 people to achieve your goals, organize into multiple smaller teams that can stay focused and spend less time trying to keep one large team on the same page.

6. Get Started Early

This tip does not mean jump in without in planning, but it does mean don’t wait until you have every single one of the answers before making progress. Many organizations want to know how long it will take to complete the rewrite that, by the way, is going to use brand new technology with a team that has never worked together before to implement requirements that aren’t well documented. Yes, these types of estimates are needed for getting funding and for acquiring resources, but you won’t really be able to validate that these estimates are close until you get started.

Early in the process, even before you know exactly which technologies you will be using or what design approach to take, form teams and start developing prototypes. Sometimes the word “prototype” implies throw away. In my experience, more times than not, the prototype becomes the base for the rewrite. Some of the code developed during this time is thrown away but that is a good thing. It is better to find out something was a bad idea while early in the cycle with a small team than later on – when it’s really hard to steer in a new direction.

7. Embrace Refactoring

Hopefully, you’re not still measuring productivity based on lines of code. There have been many occasions where the most productive days were spent eliminating lines of code. I have found that it is much more productive to write code early, before all issues have been flushed out, and then refactor once new information arrives. This is especially true when defining an inheritance hierarchy. If you have only one subclass, but know that others are coming, don’t subclass yet. Wait until the other subclasses surface and then refactor. One of the worst pitfalls for rewrites is the fear of refactoring. No one can get everything right on the first pass and trying to do so will be more expensive than doing it the best way you can now and refactoring later.

8. Automate Testing

Actually, you cannot embrace refactoring without automating testing. The first time you code a part of the system, you should not call it done until your automated tests are also complete. If you are using 2-week sprints for your development, and 7 sprints in you decide to refactor functionality that was completed in sprint 3, you need some way to make sure all the previously working functionality still works. Automated tests provide you the confidence that your code is not fragile. If a later piece of functionality changes something that was already working, your test should show it.

Beware, however, that the automated tests are code too. These must also be maintained. Choosing the right set of tests is important. My advice is that all code at all levels needs non-trivial unit and integration tests, and that automated test scripts for testing the user interface should be minimized. UI tests are the most expensive to develop and maintain and if your unit tests below the UI are done correctly, your UI tests are mostly testing navigation and interaction. The bottom line is that automated tests to take time and effort but this cost will return some of the value on your project.

9. Focus on Maintainability

This is probably the topic that got you here. Your new system must be maintainable, extensible and not fragile. All of the tips above have a maintainability aspect to them so I won’t repeat them here. The one additional point I will make is that developers should rarely, if ever, be clever. While there are many very smart developers who will take pride in writing code in a way that saves a 1000 lines of code or 15 classes, this code is rarely ever understood by those who have to maintain it. Encourage your developers to follow established patterns, reuse code and frameworks, and to always write clear, understandable code.

10. Be Practical / Don’t plan too much for the future

My last tip is the one that I rely on the most. Be practical. Too many times, in an effort to avoid future enhancement problems, designers of the new system try to plan for everything. Even though you might need a someday support mobile devices or live in the cloud, if you have no current requirements, don’t introduce complexity into your application for it now. Good architects and designers can provide guidance on what to avoid that will make implementation of these technologies in the future, but don’t write code for anything you don’t already have requirements for. If you use a layered design, write really good object-oriented classes, incorporate automated testing, and embrace refactoring, you will be able to incorporate future requirements without a major overhaul.

Final Notes

Hopefully, for many of you, these tips seem like common sense and are behaviors that you’ve been employing for years. For those who have been locked away in your legacy towers for years and are afraid of coming down to the current world of technology; never fear. Application rewrites can be a huge success and can make moving forward into the future a pleasure rather than a burden.

— Keith Shakib,

  • Share:

One Response to “Don’t Fear The Rewrite”

  1. Lou Mauget says:

    Right on, Keith. You’ve described my intermittent world of migrating outdated technologies, tools, no doc, with nobody living that understands the code. Kick it and see what happens. I’m thinking of Cobol written before even structured programming was in vogue — literally from the previous century and millennium.

    Not so sure that pure object-oriented will always be the only choice for reusability or maintainability. We’re getting into multi-core exploitation at the same time we’re seeing mega-huge scaling requirements. Speed per core is flattening (perhaps until new paradigms like quantum computers). The functional programming of the academics and Lispers is in our faces now. There are discussions about nouns vs. verbs, mutability vs immutability, lazy vs eager, shared state vs. private state, software transactional memory, hot-deployment, and more. This could be painful for us “procedural” folks. :-)

    This is in no way a negative comment on your excellent blog post. Item one just dislodged an opinion about a possibly interesting future in Geek-World. I was born too soon.

    -Lou Mauget

Leave a Reply

Things Twitter is Talking About
  • .@jessitron Good luck, you'll do great! Our team really enjoyed your KCDC14 talks.
    September 18, 2014 at 10:19 AM
  • RT @woodwardjd: 7 deadly sins of programming. I think I did all of this last week. #strangeloop
    September 18, 2014 at 10:03 AM
  • In Part 2 of our series on creating your own #Java annotations, learn about processing them with the Reflection API -
    September 17, 2014 at 3:18 PM
  • We send out our free monthly tech newsletter tomorrow - dev tips/articles via email. Not on the list? Sign up:
    September 16, 2014 at 2:58 PM
  • Want to chuckle? If programming languages were vehicles - #funny
    September 16, 2014 at 11:41 AM
  • In Part 2 of our series on creating your own annotations, learn about processing #Java annotations using Reflection:
    September 16, 2014 at 9:06 AM
  • Don't miss @jhackett01's newest post on the Keyhole blog - Processing #Java Annotations Using Reflection:
    September 15, 2014 at 12:02 PM
  • We're pretty excited - Keyhole's #BikeMS team raised 158% of their fundraising goal to benefit @MidAmericaMS. Plus, they had a great ride!
    September 15, 2014 at 10:38 AM
  • A huge welcome to David Kelly (@rheomatic) who officially joins the Keyhole team today! :-)
    September 15, 2014 at 10:00 AM
  • Sending warm thoughts to @eastlack, @cdesalvo, @wdpitt & all participating in #BikeMS this AM. Thanks for helping in the fight against MS!
    September 13, 2014 at 8:10 AM
  • .@rheomatic We are so excited to have you joining the team! Welcome :-)
    September 12, 2014 at 4:11 PM
  • As the official holiday is a Saturday, we're celebrating today! Happy (early) #ProgrammersDay to you!
    September 12, 2014 at 1:55 PM
  • Tomorrow @cdesalvo, @eastlack, & @wdpitt are riding #BikeMS to benefit @MidAmericaMS. You can get involved, too -
    September 12, 2014 at 11:00 AM
  • RT @AgileDevs: 5 tips for great code reviews
    September 11, 2014 at 2:53 PM
  • The BEMs of Structuring #CSS - A quick introduction to the Block Element Modifier methodology.
    September 10, 2014 at 2:49 PM
  • A huge welcome to Joseph Post (@jsphpst) who has joined the Keyhole team this week!
    September 10, 2014 at 9:52 AM
  • @TheGrisExplores Absolutely, and thanks for the compliment! Here's an article that you might find helpful, too -
    September 9, 2014 at 2:22 PM
  • Express.js seems to be the top pick! MT @TheGrisExplores: "what's your fave server-side MVC framework for NodeJS when SPA is not an option?"
    September 9, 2014 at 1:56 PM
  • RT @TheGrisExplores: Yo @KeyholeSoftware dudes and dudettes: what is your favorite server-side MVC framework for NodeJS when SPA is not an …
    September 9, 2014 at 1:15 PM
  • There is a new post on the Keyhole blog by @brianletteri - The BEMs of Structuring CSS:
    September 9, 2014 at 12:12 PM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2014 Keyhole Software, LLC. All rights reserved.