Imagine that you’re starting on a new project. It’s all very exciting. The team meets, and together you plan your attack. You start working away, and you’re having a good time. Pretty soon though, you find all compromises, misunderstandings and bad decisions made in the code you’re there to build on. Welcome to the real world – you are working with legacy code.

You can decide that there’s just too much untested, hard to understand code. There’s no way the project can rewrite it and still produce the new features that the business wants. The team will have to live with it. Besides, this code has been tested by real users for years, and you can’t just throw that away.

On the other hand, past shortcomings are slowing you down to a crawl.

Some of the enhancements planned for the project require changes in the old code, and that’s a pain to do. Also, the project has to fix a number of bugs, and you don’t even know where to start looking for those. You realize that if you don’t rewrite the code, there’s no way the project can deliver on time. You are stuck between a rock and untested code.

The trick is, of course, to rewrite just enough to give the necessary velocity. The hard part is to know what and how much to rewrite. In the last project I worked on, my colleague Jim Arnold showed us one way of keeping track of what is hurting us at the moment. We took a flip chart and every time we’d find that we where struggling, we’d write the name of the class that was giving us a hard time on an index card. We would add a line on the card, and then we stuck the card up on the flip chart.

If the class caused problems again, it gets a second strike.

By now, you’ve probably already figured out what happens next. Whenever a class gets a third strike, it was time for reworking. We would spend time working on the test coverage. We would take out anything that wasn’t used. Taking baby steps we would improve the design until the change we wanted to do became easy and safe. A few times we found that it as faster to just rewrite a bunch of classes from scratch than take lots of small steps.

Of course this is not a perfect system. But it helped us to be a bit more objective about what actually needed to be fixed, and what could wait. Some people lean towards patching the code until it does what he wants, and a some always want to chuck the whole thing and start fresh. This system was a compromise between the two.

Most projects are not greenfield projects. Working with legacy code (even if it’s something you wrote yourself, when you didn’t know better) is something you should expect to do. So building on your set of tools for doing this effectively is essential for you to become a kick ass developer. It’s not enough to learn the latest frameworks or the new cool dynamic language.

Posted by Andres on Saturday, March 24th, 2007 at 14:19.