A Debate on Tech Debt

Gleaned shamelessly from a Slack chat: musings on the concept of technical debt

Alessandro Morandi

http://laughingmeme.org/2016/01/10/towards-an-understanding-of-technical-debt

I found the analysis in that article very interesting. Technical debt has become such an all-encompassing term, it’s useful to be reminded of what it actually means.

Lukas Oberhuber

Kellan Elliott-McCrea argues that only a very small portion of what he lists is actually technical debt. I disagree — I think he’s excluding too much.

I do agree however that “2. Features of the codebase that resist change,” is an area that is not tech debt. No one can build a system that can handle all changes, or even predict them, so the fact that some of them may be hard to do should not qualify as tech debt.

I think splitting debt into many categories is absolutely fine, but the cost of changing the codebase/system is real. Technical Debt (in my head) is all about the difficulty of making changes. The fixes are many and need to be understood to be successful. I strongly believe you can pay off Technical Debt, but you’ll never pay it all off.

But systems with less tech debt last longer and can scale to more functionality (see reference here.

Here are two videos of my talk on the subject: technical bankruptcy at APM, and technical bankruptcy at CukeUp 2015 (registration may be required). Or just the slides here

Alessandro

That article resonated with a couple of thoughts about Tech Debt I was considering recently. To me, Tech Debt is often portrayed as the consequence of something that was ​done wrong​.

I think of it more as an inevitable consequence of time. A bit like wear and tear, there’s no way of avoiding it. You can build a system that’s more resilient, but eventually you’ll have to address some issues because that’s how artefacts work in this world.

(I’m not saying that’s your view by the way 😉 )

Lukas

I think complexity is inevitable and causes some problems, time is inevitable and means that change is needed, but tech debt is inevitable because we usually have delivery deadlines.

However, you can also pay it down again. Kellan Elliott-McCrea is talking about some things that happen not because they are done wrong, but that they no longer apply. I agree those aren’t tech debt, unless you fail to make the change when it is needed. When that happens you instantly get a huge pile of tech debt.

Alessandro

One consequence of the way of thinking about Tech Debt I outlined above is that you need a two-pronged approach: on one hand you can try to prevent it by building a resilient system; on the other hand, you have to constantly pay it off to avoid the system decaying, no matter how good it was in the beginning.

Lukas

Maintenance is a must, and failure to do it turns into tech debt. Doing it is avoiding that debt, so I think we are in agreement.

Alessandro

Yeah, it’s semantics now 🙂

I think you’re calling it Debt once it becomes a sore spot, while I tend to extend that to the constant wear and tear.

Lukas

So when we change Insurer into Provider [ed- a domain model change we did recently], that’s not tech debt. That change is a consequence of needing to change. If we then decide to do it only on half our systems, that’s debt. Leaving it as is in so many places means that now everyone needs to understand that the two things are the same most of the time, but not always. That’s tech debt.

Doing it at the right time, ‘wear and tear’ is preventative maintenance.

Alessandro

Yeah, I see what you mean.

Lukas

Potholes are an inevitable consequence of winter, however not fixing them over time turns a safe road into a road that causes accidents which is then debt (not tech, but debt nonetheless).

Alessandro

I would have said that changing Insurer into Provider is ​paying off​ tech debt, which we have accrued when time changed our situation.

Lukas

Think of the London Tube. All those signal failures are debt. [ed- these happen way too much]

Changing Insurer to Provider is a new feature as we change the domain model of our business. Doing it at that time avoids the debt of not doing it.

But yes, semantics. Like not having to take a loan since you didn’t need the money in the first place.

Alessandro

Yes 🙂

Lukas

Typically paying off your bills in time is not considered debt 🙂

Alessandro

Yeah, in that sense it’s only debt when you’re accruing interest.

And I remember a similar concept in your presentation.

So in a sense tech debt generates more debt the longer it’s in the system. Changing requirements don’t.

I still wish we had a better term for when you have to do work because the domain has changed – or your knowledge of the domain has changed. “Tech Debt” is a pretty neat shorthand and I’m not surprised it’s (mis)used everywhere.