I’ve been hearing people talk a lot more about Technical Debt recently. I’m glad. Anything we can do to pay more attention to long term quality is good. Technical Debt is a valuable frame for those discussions. No one wants to be in an impossible situation and teams that keep accumulating Technical Debt often end up there. It’s a land of risky rewrites - which are essentially an attempt to dig out of a hole.

When I wrote Toward a Galvanizing Definition of Technical Debt what I was doing was describing a different frame - sharing a way of viewing things that leads to an outcome I’ve seen on teams I’ve worked with. It turns out that if you think about code in terms of ease of change in concrete cases, many of the design principles that we’ve identified in software don’t have to be targeted specifically, we just start arriving at better design through discussion and work. We start to ask the right questions - and asking the right questions is key to finding answers that matter.

Back to Technical Debt. Yes, it’s a metaphor, but it’s not “just” a metaphor. One thing that I believe is true is that the stuff of life falls into patterns and when we notice the same pattern in different places, there’s usually a deep systemic reason even if we don’t know what it is.

Earlier this year I wrote about the universality of Postel’s Law. It’s amazing to see it as a design principle that applies to physical systems and social systems as well as software. Why would that be? I think it has to do with what I mentioned before. There are certain patterns emerge over and over again in systems regardless of what they are "systems of."

Technical Debt, like most good metaphors, is more than a metaphor - it’s an accurate read of dynamics in a system. If our goal is understanding, deep metaphors help us, but we can employ metaphor to do a lot more.

I was at a workshop on Technical Debt at Calvin College years ago and I remember being agitated midway through. I started thinking that framing the issue as debt is good but for the most part people are inured to debt. A thing that is more universal is the feeling of loss when we lose something of value. What if we see software as a thing that can lose value over time?

Imagine the conversations - we made these changes in this iteration. We had to do feature A fast, so the value of the code base was diminished by X amount.

It’s an interesting frame but, as with technical debt, there’s the question of how you measure it. There's also the danger of venerating existing code. Once you start seeing code as an asset you can get into all sorts of conundrums like - we can’t get rid of that code, we invested 30 years in it. It has value!

That said, flipping the frame on Technical Debt to turn the discussion into how do we prevent the loss of value in our systems may be useful at times. Declan Whelan and Andrea Goulet have explored this frame a bit.

It all depends upon whom we’re communicating with and what we want to achieve. That’s the power of metaphor.

A friend of mine told me that an aviation company he was working at, he was able to communicate the need for refactoring using a completely different metaphor. He pointed out that all aircraft have service plans. Regulatory agencies mandate that certain checks and service occur at particular times related to number of takeoffs and landings and air miles. He said that code has the same issue. After a certain number of changes, a file, class or component should go in for maintenance. That was all it took to communicate the need for refactoring in that domain.

What I wonder about now is whether we really need to adopt the tool of metaphor to communicate with business. Why aren’t we all on the same page already?