The amount of software in the world increases in a rapid pace, so does the amount of legacy systems. If you are a developer with some years experience I’m sure that you at some point have had the pleasure of having to do a change, like fix a defect or add some functionality, in an old, messy codebase. Sometimes, the bug fix or adding of the new feature goes well, and you move happily on to a new task or a new project. Sometimes though, the pain of working with the system might just get unbearable. Each change takes forever and you are constantly afraid of breaking some important functionality (true legacy systems have no tests). You may have experienced this too. A little over 1 year ago, in May 2011, I found myself in such a situation.
I had pulled a story where the goal was to upgrade an EJB 2 legacy application to run on Java 1.6 and change the build system from Maven 1 to Maven 2 (sigh). Task seemed simple enough. It turned out to be everything but. To cut a long story short: I had huge problems upgrading this application to Java 6, I simply could not get it to run properly on this JVM. The application itself was simple enough, a couple of screens, but the amount of over-engineering was basically making it into a big ball of mud.
Make the Change Smaller
If you want a reluctant elephant to get moving, you need to shrink the change.
Switch – Chip & Dan Heath
Getting a headache everyday and with little progress on what seemed like an easy task, re-writing the application seemed more and more like a very attractive option. Now, I’m not a huge fan of big re-writes, small improvements often produces better results IME. With some notable exceptions, including this one:
An absurdly over-engineered application, built on an obscure old Java Framework, once popular back in the beginning of this century (yes, I’m talking about EJB 2.0), built by over-eager engineers having too much fun future proofing for every possible eventuality.
No, baby steps were not going to save this application. So here is what we did:
I knew that getting money to re-write the application would be very hard. This was an important application however, and one that the customers were increasingly unhappy with. In terms of customer value I had a strong feeling that re-writing the application was the right thing to do. So I decided to hack a little prototype in the evenings, after the kids had gone to bed. With Play Framework I pretty soon had a working prototype. My good friend and colleague Christer volunteered to style the application with a modern look-and-feel, also during evenings. Once we had something worth showing we invited business to a meeting where we demoed the application. The response was overwhelming. They loved the application and they loved the initiative. We had proved with very little work, that it was possible to create a new application to substitute the existing one. With this information they were able to get money to fund a re-write of the application. Late December 2011 we got the green light to start rewriting the application to a modern web application. The application is now in acceptance test and hopefully we can roll out the application early autumn 2012.
By shrinking the change and showing people in the organization what is possible to do, we were able to raise money to re-write a big, nasty, old legacy EJB 2 application that customers hated, into a modern web application based on the Play Framework. And hopefully a web application that customers like and find easy to use.
“Shrink the Change” is taken from the Heath brothers excellent book Switch – How to Change Things When Change Is Hard. If you haven’t read this book yet I think you should. It’s one of the best business books I’ve read. Well written with lots of good advice on how to go about changing things. The video below shows a small clip