How to Survive a Software Rewrite
Beware of the hidden sirens in your rewrite project. They will sing the words you want to hear--that the project is easy to complete. Don't be fooled: Sirens are mythological, but the lure of rewrite projects can be quite real. Rewrite may seem a simple task, but it isn't until you're deep into it that you'll start to realize the true nature of the project. In this article, James Shore offers some words of wisdom (and warning) to help guide your rewrite project in the right direction.
The following is only funny if you're not living it. I present the five stages of the software rewrite:
- Elation "Yay! We've finally thrown off the yoke of that crappy, buggy product! We get to start over, and by God, this time we're going to do it right!"
- Buckle Down "There's a lot of work to do here. We'd better get to it."
- "There's a metric (censored)-load of (censored) work here. We're not going to get done on time. All this stuff we've been doing, like testing, designing, and integrating, is nice in theory, but we've really got to start cranking code or we're never going to make it!"
- Exhaustion "We've missed our deadline again. (What was that, number three or thirty?) Better call the family and tell them we'll be working late again. Six months of overtime--it could be worse, right?"
- Relief--"We finally released! It's buggy and the design is kind of crappy, but at least we're done! It didn't turn out too well, so we'll need to rewrite in a few years. And next time, by God, we're going to do it right!"
Moral of the story: Rewrite projects are tempting and dangerous. They're tempting because they always look easier than they actually are. They're dangerous because you can't release the new software until you've completely replicated the functionality of the old software. That takes a lot longer than you expect. Meanwhile, you're spending tons of money, you're getting no new revenue, and your old product is falling further and further behind the competition and the users 'needs. This leads to pressure, which usually leads to throwing out all the good software practices that were the reason for the rewrite in the first place.
If you want to survive a software rewrite, don't throw away your existing software. Instead, identify what it is about the new software thats going to be valuable to your users, and work on those pieces first. Write the code in such a way that it coexists with your existing software, perhaps as an optional add-on that you can sell.
If you're not changing core technologies (language or platform), refactor your existing code as you work with it. Some pieces might be cheaper to rewrite than to refactor, but don't jump to that conclusion. Instead, take it on a case-by-case basis, and when you do rewrite keep the pieces small and timebox the effort to days, not weeks.
If you are changing core technologies, still focus on what's valuable to your users. Take the time to integrate your new software with the old software so that you can deliver incrementally. Identify pieces to rewrite based on end-user functionality and value, not technology, and rewrite based on value. Again, timebox each mini-rewrite effort to a matter of days, not weeks.
In either case, keep your software integrated and ready to release at every step along the way. If you're already in the midst of a rewrite, stop everything now and start working on integrating and getting to releasability. You'll be shocked at how hard it is.
This approach sounds like it takes a long time. It does, but you can release as you go, and it’s a heck of a lot better than going through the five stages above.
Related material:
- Things You Should Never Do, Part I (Joel Spolsky)
- Design Debt (James Shore)
