jump to navigation

Friday Philosophy – “Technical Debt” is a Poor Term. Try “Technical Burden”? June 30, 2017

Posted by mwidlake in database design, development, Friday Philosophy, Management.
Tags: , ,

Recently my friend Sabine Heimsath asked a few of us native English speakers what the opposite of “technical debt” was. My immediate reaction was to say:

I’d say (sarcastically) “proper development” or “decent designer” or even “what we did 25 bloody years ago when we were allowed to take pride in the software we created!”

But my next comment was less reactive and more considered. And that was to say that I did not like the phrase “Technical Debt”:

A debt is when you owe something to someone, to be paid back. You do not owe anything to someone when you build poor systems, you are actually creating a “technical burden” – something those in the future will need to live with and may eventually have to sort out. Those who created the bad app or design will probably not be the ones fixing it – as in paying the debt.

That is of course not always true. Some of us have had to end up fixing a poor solution that we implemented – usually implemented despite our protestations that it was a daft thing to do. But the usual case is that a badly thought-out solution is implemented in a rush, with little design, or with inadequate testing, because of a management pressure to be “agile” or “fast moving”. And it is done with cheap or over-stretched resource.

Also, “technical debt” to me sounds too organised and too easy to fix. If you have a financial debt, you simply pay it back with some interest. In almost all situations I have seen where there is a “technical debt”, the interest to pay – the extra effort and time – is considerably more than was saved in the first place. Sometimes it is more than the original cost of the whole project! Loan Shark territory.

When the poorly designed/implemented system falls over in a heap sometimes the hard-pressed local staff lack the skills or bandwidth to fix it and “Experts” are called in to sort it out. And part of the time taken to fix it is the expert going “why in f**k did you ever think this was a good idea?” (Maybe using better terminology, but that is what they mean!). Being more serious, sometimes the largest slice of time is when as an “Expert” you have to persuade the people who own this mess that it really does need sorting out properly, not just another quick hack – and it really will take much , much more effort than what they originally saved by deciding to implement this fast & dirty. Sorry, I mean “lean & mean”.

This situation often has a secondary impact – it makes the people who originally implemented the solution look poor. And that may or may not be fair. I’ve seen many cases where the original staff (including myself) were forced to do things they did no like by timing constraints, lack of budget or simply the ridiculous demands by someone higher up the organisation who thought simply shouting and demanding would make good things happen. They don’t, you end up creating a burden. Though I have also seen poor solutions because the original team were poor.

I think at the moment a lot of what is called “systems development” is more like a desperate drive to constantly cut corners and do things quicker. If it goes wrong, it’s just a debt, we pay it back. No, no it is not. It’s often a bloody mess and a Burden for years. I keep hoping that, like many things in I.T. this will be a phase we can cycle out of and back into doing proper planning and implementation again. Yes, anything that speeds things up without losing planing/design is great. And if you have the skills, you can do proper Agile, designing the detail as you go – IF you have the general over-arching design already in place. But I wish there was more consideration of the later cost of quick & dirty.

So what was the term Sabine wanted? Well, I can’t speak for her, I am not 100% sure what she was looking for. But from my perspective, we should not say “Technical Debt” but “Technical Burden”. And the opposite might be “technical Investment”. You spend a bit of time and effort now in considering how you can create a solution that can expand or is flexible. I know from my own personal experience that it is when you are given the chance to do those things that you provide a solution that last and lasts and lasts. Only when I have been allowed to properly consider the business need do I create something still used in 10 years. Or 15. Or maybe even 20. That might need some checking!

So, if you really want to build systems to support a successful business, and not a short-lived flash, perhaps you should be saying something like:

You are asking me to create a Technical Burden. Would you rather not help me create a Technical Investment?

If anything else, you might at least be adding a new entry to “Buzzword Bingo”.


1. David Harper - June 30, 2017

Another aspect of this problem is the tendency of many developers to build mission-critical systems using the latest bleeding-edge language/library/database/web framework because that’s what all the cool kids are doing this month, without any thought as to whether the said technology (a) is mature enough and stable enough yet for deployment in a mission-critical system and (b) whether it will still be supported in five or ten years time.

There’s also the rather cavalier attitude of the creators/maintainers of some languages/libraries/etc to backwards compatibility and long-term stability. Java and Python make an interesting contrast in this regard. Java was the language that all the cool kids used in the early 2000s, but these days it’s regarded as boring and very uncool, and Python has taken its place. But Python has two distinct versions — 2.7 and 3 — that are not compatible with one another, in the sense that a Python 3 interpreter cannot run most Python 2.7 code. The guardians of Java, originally Sun and now Oracle, took a much more cautious approach to backwards compatibility, so most Java 6 code will compile and run just fine in a Java 8 JDK. Okay, you might get a few deprecation warnings from the compiler, but at least the damn code runs. Sometimes, boring is what you want, especially if you find yourself looking after a software stack that someone else wrote ten or more years ago.

2. Robin Moffatt (@rmoff) - June 30, 2017

Interesting podcast on related matter https://www.infoq.com/podcasts/adam-tornhill
Posits that technical debt is often more organisational debt, and also that sometimes technical ‘debt’ is actually best just left alone…

3. mathewbutler - June 30, 2017

I posted a long comment and the lost it to during wordpress password reset.

The short version is that the metaphor is badly used. It’s used not as it was originally intended.

Here’s Ward Cunningham explaining his intention when invoking the metaphor, and the context it was created in.


mwidlake - June 30, 2017

Thanks for that Mathew – I had not appreciated that the phrase originally had a more specific and reasonable meaning, as the link says. I’ve only come across the phrase as used incorrectly for “bad or buggy code”.

4. jgarry - June 30, 2017

Funny you mention the 10 or 15 or 20 years… I was called into this place 16 years ago to fix performance problems due to the Rapid Application Development for customization, as well as some business design decisions that were (and remain) questionable. I’m still fixing things no one has noticed has been wrong this whole time…

Replacement is in the works, but that has been for a while too. It’s all kept a mystery to me, though I have noticed some very bad data suck attempts that are right in my ballpark. We’ll see.

Someone (with a Masters in Biology) asked for job advice on another forum, asking about how to become a system administrator. He mentioned he had done some scripting in Excel. A local blowhard totally denigrated any scripting language saying ” end user experience can’t be counted towards IT any more than commuting every day qualifies you as a mechanic” and in response to someone taking issue that scripting is more than end user stuff “Scripting is just normal end user stuff. It’s just basic computer literacy.” I suggested that programming is the intersection between what he knows and computers, and to google scripting job biology, since that pops up lots of python jobs. And I held back going full flame about what big data work is.

The bright side is, the more burden, the more job security. Though that may not be fun, and boy, are we gonna see some large scale damage in the meantime.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: