A while ago I witnessed an interesting conversation about alternatives to the term technical debt.
I think it’s interesting to explore those alternative metaphors a little bit: they may shed some light on what technical debt actually is, how to think about it.
This is particularly important since it can be so frustrating to get non-technical people to understand it, and that it must in fact be addressed.
And it doesn’t hurt for us to explore the concept as well.
So here are a few alternatives that were tossed around:
Code Pollution
Some suggest the term “code pollution” instead.
It’s certainly interesting, as pollution is of course noxious and undesired and should be cleaned up.
What’s also interesting is to realise that while the magnitude of debt is know in advance, the same may not be true of pollution. So it may convey the (correct) impression that this is something that must be explored, can’t be quantified well.
Pollution might also spread, or have unexpected side effects. In that sense, it captures many properties which can in fact be found in polluted code.
I wonder, though, if pollution pushes the blame too much towards the engineering side of the organisation. In the sense that those who make the fire also make the smoke. But that’s not all, of course.
While some aspects of technical debt come from engineering decisions, others come from other parts of the business: incomplete requirements, for instance.
More crucially though, pollution is always undesired. Debt, on the other hand, may be knowingly, deliberately taken on for some ulterior reason. And that’s OK, provided that it’s managed adequately.
Technical Entropy
For people with a more scientific bent, entropy may be a nice metaphor. Especially since entropy is inescapable, it’s just something that happens in a real universe. And removing it requires energy.
But yet again it doesn’t convey that sense of something that might be deliberately incurred and managed.
Technical Inertia
Yet another physics metaphor. What’s interesting about this is that it embeds in itself the notion that keeping the current direction, not changing your approach will be the path of least resistance.
It’s nice in that it reminds us that effecting change takes effort, may be unpleasant.
…and that in turn gives rise to another important point. Maybe this inertia should be sidestepped: “Make the change easy, then make the change”. Don’t just confront the issues head-on if you can avoid it. Be smart, but keep changing things for the better.
It also raises another important point: maybe the inertia has carried us into unfavourable terrain. Maybe it’s not even that our software has become worse, per se, but the environment it operates in has changed.
Software Weeds
A nicer image, perhaps, is that of software weeds. You could embed that into a whole metaphor of software development as gardening.
And it also brings with it the idea that weeds may spring up without our actively doing something. They just… grow. And we need to deal with them.
What now?
Maybe you were waiting for shootout between these metaphors, some kind of argument about which one is best. But I think there’s no sense in finding a “best” metaphor.
As a smert person pointed out, “all models are wrong, but some are useful”. And so it is with these metaphors. Of course they’re incomplete, and break down at some point.
But perhaps they give you an arsenal to explain particular aspects to your colleagues or your manager. Or maybe they’re food for thought for yourself, to explore your product and its progression from a different angle.
Or maybe they’re just fun.