In the last 19 years I've spent a lot of time on product rewrites. I know Joel says you should never do it. But sometimes you just have to – especially in the enterprise space. Like the rest of you, I've had both success and failure – and I keep learning. It's not something that you can cookie-cutter. That said, I've developed my own rules for managing a product rewrite that I thought I'd share with you today.
1. Resist the need to change everything.
The truth is that your old code, assuming it was in production and supported a lot of customers, worked. There are a lot of reasons to migrate your codebase (a completely different topic worthy of its own post), but no one should step into a rewrite saying, “We have to do everything we used to do, but we're going to do it in a completely different way.” Unfortunately, I hear that all the time.
Often it's because you move from Windows to the Web, or the Web to Mobile (or green screen to Windows, anyone?). So because you're changing platforms you think this is the time to change common interface metaphors and more. But those metaphors are ingrained in customer's minds. So when you change that, you're creating the need for new training. You're also introducing risk because people will say, “If I have to start all over, I might as well look at the whole field of candidates.”
2. Resist the need to duplicate everything.
On large enterprise systems the big rewrites are the worst because the old product manager may want every single feature ported to the rewrite. But don't do it. Instead, determine what portion of the system is used regularly. I once worked on a rewrite where the core of the application was used regularly but tons of other features were never touched. We were able to shrink the product's feature group by 40% simply because no one had bothered to ask, “What's being used?” Rewrites are risky. Don't add to the risk by making them any larger than they need to be.
3. Resist the desire to hide in your cave.
I know – you're thinking that if you could just go hide in that dark room with the limited light just cascading off your desk from your large monitor, and could work in peace, that everything would be better. But it's not. You're going to want to talk to people constantly. Keep your own teams in the loop so they're not surprised. You would be amazed how much stress is created in an organization when a bunch of people don't know until the last minute, that you're introducing a rewrite. The biggest detractors of the new code are your own staff. Keep your teams “in the know.”
4. Resist the desire to announce your rewrite.
While it's critical that you keep your internal team in the know, and on board, I don't recommend announcing it to the world. After all, they don't care about your rewrites. They care about the benefits of using your software. So making the announcement is like saying, “Attention: we're going to be so busy for the next xx years that we won't have any time to really support you so I suggest you start talking to our competitors.” Now, seriously, do you really need to do that?
5. When you do announce a new version, whatever you do, don't miss your deadlines.
When it comes to product development, the relationship you have with your audience relies on a couple of critical components – your features have to work, your support has to be awesome, and you have to hit your dates. When you're doing a rewrite, your dates are even more critical because you've changed some core stuff, and your clients are going to want to know if they can trust you. Missing a deadline is stating that you're not trustworthy. But don't go the extreme and never put out a deadline either. When you're close enough to your target, fix a date and get people focused on delivering about 3-5 days early. Done well, it will give you the right amount of time to prep for your release.
This applies to more than the Enterprise space
The title of my post suggests I was going to tell you how to screw up a product rewrite. It's simple. Break any of these five rules and I think you're there. Break any two and I know you are.
And as I read and re-read my list, I couldn't help but be reminded of a recent product launch that broke most of my rules.
So now that I think about it, these aren't just for enterprise software. I think they apply to all kinds of software. What do you think?