The following is only funny if you're not living it. I present: the five stages of the software rewrite.

1. The Elation stage. "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!"

2. The Buckle Down stage. "There's a lot of work to do here. We'd better get to it."

3. The Oh Shit stage. "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, integrating) is nice in theory... but we've really got to start cranking code or we're never going to make it!"

4. The Exhaustion stage. "We've missed our deadline again. (What was that... number three? Or number thirty?) Better call the family and tell them we'll be working late again. Six months of overtime... it could be worse... right?"

5. The Relief stage. "We finally released! Okay, 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's 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/user 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 that's going to be valuable to your customers/users. Work on those pieces first. Write the code in such a way that it co-exists 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 customers/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.

And in either case, please, please keep your software integrated and ready to release at every step of 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.