The Rebuild Trap

Another post in my series about common traps that organisations can get themselves into. This week we will look at a really common one. I think I have seen this in one form or another at every organisation I have ever worked for. It's really easy to get into. Once you are in it, it's really hard to get out of. But fortunately, once you know what you are looking for it is really easy to avoid. It's the rebuild trap.

It works this way - the product or process you are working in is becoming old and inefficient. The code base is old and riddled with tech debt. Technologies have gone out of date. It's becoming slower and slower (and more and more expensive) to add new features or other changes. Finally the organisation throws up its hands and announces that the system will be re-built. Everyone cheers. Out with the old, in with the new. A team is stood up. Everyone fights to be on the sexy new rebuild team rather than the boring old legacy maintenance team. Work begins and...never ends. The new system never gets delivered. The old one never gets replaced. Large amounts of money are spent with no result. The other possible outcome is that the new system eventually gets delivered, very late and with vastly less functionality than the one it replaces. What went wrong?

The problem is that rebuilding a system from scratch takes significant time. During this time, the business doesn't stop. They need enhancements, changes, updates, tweaks. Remember that legacy maintenance team? They aren't sitting on their hands all day. They aren't just keeping the lights on. They are adding new features for the business. They can't wait for the new system They need that new feature now.

What this means is that the new product team is forever chasing a moving target. By the time they have identified all the requirements - the things the old system did - and started to build the foundations, the old system has moved on. The closer they get to the functionality the old system had when they started, the more the old system has changed.

Even when the foundations are built, and the new system is nearly ready, features will still be added to the old system first. Why? Because that system is in production. By the time you add the costs of cutover and migration to get the new system live to the cost of adding that new feature, it will always be cheaper and quicker to build it in the old one. Whoever is funding that new feature project doesn't want to get saddled with the go live costs, so let's just add it to the old system. Whack a change request onto the queue for the new product and let someone else handle the go live.

So, the new product team is stuck with a growing list of new features to add. The go live date gets pushed back again and again because we can't possibly go live with less features than the old system so the new system needs to catch up before it can take over. The old system maintenance team is stuck delivering features on the old system and because it's now a legacy system due to be replaced, they are doing "tactical" solutions (code for adding vast amounts of technical debt) so the code base gets worse and worse. Both teams end up in a soul destroying death march.

The end result will be either that the new system build will eventually be cancelled so all that money will be spent with no outcome (other than frustration), or someone will make the call to cut over, ready or not, and the new system will launch, riddled with missing features and bugs. Worse, because they have been struggling to play catch up, their code will be riddled with technical debt as well. So the organisation is in a worse position than before.

The problem is compounded if this is one of those vast "replace all our old systems with one shiny new system" types of project that large companies seem to love. I have never see them end well. I have seen companies collapse because of them. One healthcare company I worked for went bankrupt because they sank all their money into a doomed project to replace all their legacy products (over 300) with one shiny new product. I have seen financial organisations pour millions into core technology upgrades that are supposed to replace hundreds of legacy systems with one new core platform and end up replacing zero old systems and just adding another complex system to the mix.

Once you are in the rebuild trap, it's really hard to get out of. You really only have two options. Neither are pleasant. Option 1 is to cancel the rebuild. Wear the sunk costs and move on. Option 2 is to make that hard decision that all development on the old system must stop. No new features will be added. All development will be done on the new system only. This will mean essentially putting the business on hold for a significant period of time and potentially giving up market share to competitors. It's like escaping from a bear trap - your only options are to starve yourself until you are thin enough to wriggle out or to cut your own leg off. They will both get you out, but neither is pleasant, and both will leave you pretty badly off.

So, getting out of the trap is really hard and painful. It's much better to not get into that trap in the first place. How do we do that? It's actually pretty easy. Remember why we ended up deciding to rebuild in the first place? That's right, mounting tech debt. The way to avoid the trap is to avoid the tech debt in the first place.

Invest time and resources into keeping the code (or process, or whatever...I'm an old coding guy so I do tend to use that language but this applies to everything) clean. If you do a tactical solution, invest time in going back and cleaning out up. Or better still, don't do tactical solutions in the first place. Don't let technology go out of date. Progressively upgrade and migrate as new technologies become available.

If you keep your code clean and up to date, the reason for the rebuild never happens. You don't need to rebuild from scratch because you are continually rebuilding. Your product never becomes legacy. You have a shiny new product to work with all the time.

The downside of course is that you need to invest time and money into keeping things maintained. That will cut into your ability to add new features. This takes discipline. It's really easy to fall into the trap of squeezing in one more feature at the expense of maintenance "just this once" and before you know it, you have walked right into the rebuild trap.