When I bought my 1940s house, it had barely any water pressure, so I hired a plumber to assess the situation. He spent a good while in the crawl space, following offshoots of galvanized piping and corroded connections. When he finally emerged, his message was not what I expected: “Son, you have some creative plumbing going on there”.
There are two things you don’t want to hear: your plumber calling you son, because he feels sorry for the pain that he is about to deliver, and the words creative and plumbing in the same sentence.
Technology Architecture as plumbing
Some choice language and a large check resolved the problem. But it also struck me as an illustration of a common problem. We often use plumbing as a catch-all for architecture that underpins the software applications that supports a business. It’s a compelling thought because it denotes something reliable, long lasting and there when we need it. Turn the software faucet on, and data streams out. Only it turns out that this plumbing is often as shaky as that in my house.
Do you appreciate the creativity in this snippet below?
It represents a thin slice of a spawning real-world architecture of capabilities and dependencies. Would you build a new solution that depends on one of these dots to be stable? Heck no.
How does it get this bad?
Information technology architects set out to design beautiful solutions, on solid patterns. Then life happens. Implementation teams may not have enough time or resources and descope non-functional requirements or fail to implement them correctly. Meanwhile, the business context changes. The solution must adapt to changes here, new features there, bolt-ons left, and incorporating tech from an acquisition right.
The business wants these changes yesterday. And so the implementers scramble. Extend this, reuse that, tweak the other. Over time, the approach is less and less successful as seemingly unrelated areas start to break, and it takes longer and longer to force-fit changes. At some point, you look under the covers and recognize the problem: creative plumbing. Organically grown.
Technical Debt
The industry term for creative plumbing is technical debt. Think of it as the debt burden that is accrued in solutions and portfolios when deviations to the non-functional requirements creep in. It affects usability, operational cost, responsiveness to change, and security. It cannot be avoided, but it can be managed.
The key is not to let technical debt grow to the point where it becomes almost impossible to address it without scrapping the solution. That’s a surefire way for applications to become “legacy” before their time: more expensive to fix than to replace.
Managing the problem with refactoring
Architects have long identified the solution to this problem: refactoring. It’s another word for preventative maintenance by fixing problems caused by taking shortcuts in the past. It’s like investing time in flossing to prevent the buildup of plaque.
Agile product teams are often good at ruthlessly reducing technical debt while developing code. They don’t go look for trouble, but when discovered in an area they are working on anyway, they invest time in improving it. Without it, agile development is not sustainable over the long term.
So why doesn’t everyone else do this too? Because it doesn’t directly lead to new features. It is often invisible to business stakeholders. For the same reason that our roads and bridges are crumbling. We allocate funds to new construction but don’t maintain what we have.
A real solution is a disciplined approach to investing in refactoring. Not to let it wait until a rainy Friday afternoon, not until these next five major initiatives are done, but right now. Allocate a portion of IT funds to prioritize refactoring initiatives. How much? It depends on the portfolio, the change rate, and the software development style. 5-10% is a good start.
This is very much a “pay me now or pay me later” proposition, and we all know what happens when we pay later. I’ll send you the name of my plumber.
Ernst Rampen ©2018
