Surviving Rewrites

It seems like fully half the projects I come across are rewrites in one form or another. It ought to be common knowledge by now that rewrite projects have a very bad track record, but perhaps the bad results are connected to the inordinate attractiveness of “doing it right this time.” The chance to replace the ugly production system with a new, pure, buzzword-compliant ode to software architecture is one of the more compelling siren songs for developers. Too bad about those rocks.

Given that rewrites aren’t going away, here are the things I recommend software organizations consider to maximize their chances of avoiding the rocks (and maybe even be wildly successful!).

1. The problem isn’t as well known as you think it is. Run away from specs that say, “The new system shall do everything the old system does plus new functions X, Y, and Z.” No one knows exactly what the system does. It got to where it is today through the accretion of features, hacks, and workarounds. You’re almost guaranteed to break someone’s unofficial report when you rebuild the system “right.”
2. BDUF still doesn’t work, even if the previous version of the system already exists. Sure, you’ve architected the perfect service-oriented, social-media, domain-specific new system. Unfortunately, it’s wrong. In the end, the new system is going to look nothing like you envision. You can’t see the future any more than the previous team could. (In fact, they were probably replacing some other system and “doing it right this time.”)
3. The customer almost always wants the existing system plus something new. By now, the existing system is probably what David Anderson calls table stakes. Since the existing system exists, you’re already in the game. Don’t start by building the table stakes again. The new features are probably spoilers or differentiators. Those have real incremental business value. If the existing system works, build the new features first. Figure out a way to integrate them with the existing system as necessary. Then grow the new system to choke out the existing one. (Martin Fowler call this pattern Strangler Application.) Eventually, you’ll have your whole new system, but it’ll bring new value from day one instead of spending months or years catching up with the existing system. It’s harder to architect a system incrementally than from scratch, but architects like challenges, right?
4. Involve the business. Don’t let them send you to the existing system as a specification. Starting with the new features makes this a pretty easy sell. Someone’s excited enough about those new features to work with your team. Keep a blend of new and replacement features through the whole project and they’ll stay engaged.
5. Release early and often. Business value can only be realized if people are using the software. Moreover, the quality of the feedback you receive will be better if your software is being used by real users with real data. This is standard agile stuff and shouldn’t come as a surprise to anyone, but rewrite projects seem to have a logic of their own.

For more rewrite project advice, check out Chad Fowler’s excellent 2006 series on the topic.

What other tips would you give teams considering a rewrite project? Share them in the comments.