The Rewrite Dilemma

Tim Rayburn // July 14, 2021

The above quote has been uttered more than once, and I'm sure that I've said something similar in my career at some point, but I can tell you several basic things about this quote: 

• The person uttering it has a fractional understanding, at best, of the complexity of the system they're talking about. 
• The leadership team spoken to is sick and tired of the challenges of maintaining the system they're talking about. 
• The project they are about to embark on will very likely overrun the budget in both time and money that has been allocated.  

Photo by Nathan Dumlao (Windows) on Upsplash

So why is this? The quote above very likely is the consultant in question simply saying what the client wants to hear. It is good for the consultant, as there will be a lot of work to engage in a total rewrite. But while the leadership team may be sick and tired of the challenges they face on a daily basis, the quickest return on investment for development comes from incremental change. Incremental change is unpopular: It requires tradeoffs. It requires investigation. But each of those changes can begin to address the technical debt which has accumulated in the system while also allowing some new features to be delivered during each sprint/iteration. Incremental change will eventually win the day. 

"But wait..." you say, "we need to fundamentally revisit the architecture of our system, so we need to start fresh" 

Perhaps you do, these situations do exist, but if that is the case, then you must remember the important lesson taught to us by John Gall in "The Systems Bible: The Beginner's Guide to Systems Large and Small": 

If you are going to engage in a massive redesign, then you would be wise to heed these words and start with a minimal new system. If you attempt to replicate all features of the existing system in our first iteration, you are designing a complex system, and as such that "cannot be made to work". 

This same axiom underpins the modern microservices architectures. We seek to design complex systems to be constructed of many small simple systems which can each be proven to function independently. It also underpins the practices of Unit Testing, testing small pieces of the system in isolation, and more broadly underpins the entirety of the movement and the concept of "Shift Left". 

Photo by Irvan Smith on Upsplash

How then can we best engage in a rational, non-emotional, discussion of the possibility of replacing a system? I recommend the following steps: 

1. Perform an analysis of what the desired future state of the system is. This should be the same regardless of incremental change or massive redesign. Get agreement on this choice of the desired goal, and focus all future conversations about the project always on this goal. 
   
2. Challenge the existing team to draw up a plan for what it would take to make the transition to this desired future state. They know the system best; they have the context. It will be tempting to engage consultants for this work but resist that temptation, consultants can advise the process is necessary, but the context within your team is critical to this work.
   
3. Estimate roughly the amount of work it will take to do the ground-up redesign.  Remember all the critical pieces that are so often overlooked such as operationalizing, deployments, infrastructure setup, retraining, and reskilling.  Then remember that human nature makes us very bad estimators, and factor in both how confident you are you have all the requirements captured, and how much of the new work is high-risk work that may grow.  This effort is difficult to do when you’re deeply connected with the existing system, and as such is prime space to engage a consultant.  At Improving, we have a system specifically designed to produce a better-quality output from these efforts called our Estimator Tool and we’d be happy to discuss with you what such an effort would involve. 
   

With this comparison in hand, now make a rational decision for your team and your business. It won't be easy but paying off debt rarely is. The reality is that you're facing a classic financial problem: Is it easier to pay off this debt than to declare bankruptcy. 

Choose wisely.  

If you are struggling with that choice, or the analysis before the choice, we can help. Please reach out.