The Renovator's Dilemma: "When Software Gets Old"

We bought a place in the country. The land is beautiful, the location is perfect, but the house is a problem. It's not a terrible house but it needs a lot of work. So what to do? Renovate? Or rebuild? In my years as Chief Information Officer I have often faced this decision with aging business systems and now I see some similarities with an aging house. In the software development world, our tendency is toward renovation. It just seems safer. When it comes to houses, I observe (with a small sample size) that the tendency to renovate is the same, but the people with the best outcomes are the "builders".

Why do we lean toward renovation? When you watch a little kid paint a picture and she doesn't like how it's going the solution is to rip it up and start with a fresh page. Sounds logical to me. And yet with systems - and houses, it seems - we convince ourselves that miracles of renovation can happen. Let's consider why.

First of all, we tend to exaggerate the "build risk" because it means destroying something familiar that already does the job - albeit poorly. As I am finding out, there is a big psychological weight associated with destroying a functional house or taking a bad system off-line. We don't like the thing, but it's ours and we paid a lot for it. Let's give it another chance. We're not into capital punishment. The reality is that "structure" is relatively cheap in both cases. The foundation and framing of a house is a fraction of the total cost and new techniques have increased the delivery speed dramatically. Even more so, the core structures of business systems can be assembled more rapidly than ever. The "builder" can catch up to the "renovator" quickly and after that the "builder" has the advantage of structure that is architected to work with the overall design. The "renovator" ends up fighting the design.

Secondly, we underestimate the risk of "renovation surprises". What's really behind those walls? What do those cracks in the foundation mean? How bad is the integration coding? How much hardcoded junk is in the core? Renovators are like surgeons, cutting away the bad stuff and not really knowing how deep they have to go until they are fully committed to the operation. Establishing a reliable starting point for the renovation is notoriously difficult and this makes budgets and timelines unreliable.

And finally, "renovators" may be tempted by playing to the short-term. What they miss is that even a relatively successful renovation has the effect of pushing underlying design flaws into the future. Nothing lasts forever. Not systems. Not houses. I have seen systems that have been renovated multiple times across decades. The problem is that each layer of renovation adds complexity and design compromises. Done often enough, this creates a situation where the system becomes a monster that cannot be subdued without major risk (regardless of the approach). Maybe we need a rule that both houses and systems can take one major renovation and then it's time for the wrecking ball.

In summary, our bias in favour of renovation may be driven by an over-estimation of the "build risk", an under-estimation of "renovation surprises" and a lack of appreciation of the accumulated risk of multiple renovations. Now a few caveats. Of course there is room for continuous improvement of useful assets. It’s also worth noting - and this is where the construction analogy falls apart a bit - that rejuvenation of business systems can be done with partial rebuild techniques that inject modern code into an aging systems. So whether it’s a strangler pattern or other forms of progressive code swap, software engineers have tools to blur the line between Renovate and Rebuild.

In general, I think we would do well to consider "rebuilds" earlier in the life cycles of both houses and business systems. Certainly in the case of our house - which has already undergone two major renovations- it's time to start fresh.