Have you ever been part of a major rewrite? How did it go? Whether you are a developer, a tech manager, or a business user, the answer is almost certainly painfully. Here is my best estimation.
First there was a lot of excitement. New tools, new architecture, new features. The thing was going to solve it all. Remember? New team members were hired, the business trusted in the end-all-be-all solution. Time went by. Everyone dug in and started coding. Early features were demonstrated and people saw the end of the tunnel. This is about a 50% mark of a typical rewrite.
At this point two things happen. First, the business has now been holding its breath for a long time, pacing improvements to the old system, avoiding disruptions and promising customers that all of their woes would be addressed. And now the pressure builds. We need something released. The other thing is what happens in any development project – things are more complicated than they were predicted and we have had to make a few workarounds to get it together. So on top of everything, we are behind schedule.
What happens from here varies. If the tech manager has sufficient clout and charisma, he is able to hold off business pressure while encouraging the team to work longer hours, code faster, and cut scope. We begin a death march. All other scenarios are worse. Putting the rewrite on hold while just a few features will get us where we need to be stagnates the project and turns it into a tech-driven initiative that developers do in their spare time. Splitting the team with some engineers dedicated to adding features to the old platform while the rest are scrambling to bring the new one home is another common misery. The result there is, neither system gets the attention it needs and everyone is stressed. Adding resources at this stage is rare. First of all, the business has been bleeding capital for too long, and there is a sense that “we are already spending too much on tech” – and developers are often resistant to adding team members this late in the game when nobody has time to train them.
Most teams will not survive any of the described options intact. Some people move on. Some are fired because they are no longer performing at their best under this kind of pressure. Often the tech manager loses his job, or at least loses political capital. Consultants show up and things go down-hill from there.
Even if the rewrite progresses to its 80% mark, this is when we discover the million edge cases that nobody documented or really knew about, but have been in use for generations of users, and are now no longer supported and need to be crammed into the release, before or after the initial deployment. Users are unhappy and they can’t believe you took away their favorite things… All that work… for that?
Still want to do your rewrite? OK, there are times when existing infrastructure has worn out. A full rewrite is needed. Here are some things to do in order to avoid the death spiral.
1. Find a way to create an iterative rewrite with deliverables no more than a month apart. Switch out components. Separate back end and front end. You will probably need to start by refactoring existing code base to support modular architecture. It doesn’t have to be fully modular. Just enough to allow for a bridge to be created.
2. Another approach is to build a platform with no features. just the bare bones tech needed to grow toward the vision. Now pick out a customer or a use case for the platform to handle and instantly monetize. It may be a new feature that was never previously available and can attract new business, or one that could not scale or perform in other ways in the old platform. Now your rewrite begins to pay for itself. You are bootstrapping your tech! This can be a path full of rewards and celebrations, which allows the new system to be the golden horse, while features are slowly peeled off the old one.
3. Outsource it. I know, I make it sound crazy. Yet… it’s an interesting solution. Build an all-star outsource team. Remember, smart guys are *everywhere*. Weekly design reviews early, regular code reviews, mentorship from the existing team – and a low-budget rewrite is growing up while your existing team fights fires it knows how to put out. I’ve seen this approach save the day more than once.
4. High budget. Marry your CEO off to royalty… or get VCs to pony up a few million for a complete separation of the rewrite, the patience and the whole thing. Then estimate the hell out of it. This is a very high risk option. You have to be deliberate and slow and think of everything. I personally don’t have the heart for it, but it’s how big companies do it. LinkedIn managed a huge rewrite on a high budget. But be sure your CTO knows what he is doing, your team is all stars, and communication is crystal-clear. VCs hate surprises.
What are your thoughts? I’ll be adding some posts with more color on this issue.