
Technical Debt Doesn’t Exist - user5994461
https://thehftguy.com/2020/08/26/technical-debt-doesnt-exist/
======
wokwokwok
Technical debt isn’t an arbitrary thing; it’s a metaphor to try to explain
doing maintenance to non technical folk.

The explanation goes like this:

If you have no debt, you can borrow money.

If you have a bit of debt, you can borrow money, but you have to make regular
repayments of _maintenance_ to service that debt.

...but when you have a lot of debt, lenders are cautious about lending you
money. Will you pay it back? Why didn’t you pay back any of your other debts?
Can you afford the repayments?

The metaphor isn’t perfect, but the point being made is that _maintenance_ is
the repayments on technical debt; if ignore it, at some point you are going to
end up spending all your developer hours on maintenance, and your throughput
for features will grind to a halt.

You “repay” the technical debt by fixing stuff that causes problems, not by
randomly rewriting it because you can’t be bothered reading the existing
source code.

It’s not maintenance.

That’s a different thing; that’s _making changes_.

Technical debt is more like a metric of how prone to failure /what feature
velocity your software is / has.

Sure, the metaphor falls over; you can just keep slapping broken features and
other crap on top of either other indefinitely if you _dont care_ if your
existing features work or not... but, that’s a different issue.

~~~
user5994461
> You “repay” the technical debt by fixing stuff that causes problems

Well, that sounds a lot like maintenance.

~~~
lucideer
As the GP said:

> _The metaphor isn’t perfect_

But there's a difference between maintenance that fixes problems expediently
and maintenance that fixes problems more permanently. The technical debt
metaphor is an attempt to model the cons of doing the former too often
(otherwise faster always seems better).

------
gjulianm
Maintentance is not technical debt, and confusing both terms is weird. While
there are multiple definitions, I'd say maintentance is the work of making
adjustments to keep the software in a working state, say supporting new
operating systems, fixing bugs, updating to minor versions of libraries...

Technical debt, on the other hand, is quite literally a form of debt. You
borrow time from the future by developing a solution that requires less work
now, but that will need to be changed later on because it won't be enough
future requisites, and that will create additional work (interest) in the long
term while it's present. And every programmer does this, consciously or
unconsciously. Say hard-coding some parameters in functions instead of
creating user-defined options because it's easier, or writing a specific class
instead of an abstract one that can be later extended, or writing a hack
instead of refactoring so that new changes fit properly.

Of course, it's difficult to predict the future and some technical debt is
never repaid. But it's important to make a distinction and to have in mind the
technical debt in your project and when it's worth it to remove it.

~~~
DJHenk
> Technical debt, on the other hand, is quite literally a form of debt. You
> borrow time from the future by developing a solution that requires less work
> now, but that will need to be changed later on because it won't be enough
> future requisites, and that will create additional work (interest) in the
> long term while it's present

It is all just a words game. If there is an issue now, and I do a hotfix and
hardcode some stuff that surely will need work later on to keep things
working, then:

A) I created technical debt. I took the quick route now, but will have to
spend more time in the future if I want to update this code.

B) I did maintenance. A thing was not working and I made it work. This is a
simple, small bugfix, a.k.a. maintenance. In the future we might have to spend
some time to keep things working in slightly different conditions. We also
call that maintenance.

Both ways of phrasing it can help to communicate a message. But there is no
use in getting hung up on what to call it. Your job as a developer is to be
smart about it and choose the best possible trade-off. You need to do that in
both versions equally.

~~~
gjulianm
Maintenance and technical debt are intertwined, but I don't think it's just a
words game. Things without a name are less visible, and maintenance and
technical debt are different. There's maintenance unrelated to technical debt,
and technical debt unrelated to maintenance. Taking into account the technical
debt you have helps you when estimating the cost of maintenance and new
features, or to understand the possible problems when new environments come
into play.

IMHO, part of being smart about it is having the words to communicate the
concepts clearly, it's not a moot discussion.

~~~
kthejoker2
> There's maintenance unrelated to technical debt,

Agreed.

> and technical debt unrelated to maintenance

Disgareed, as you cheerfully indicate yourself in your next sentence.

Technical debt as a concept of "debt" is paid back through maintenance.

What else might it be paid back with?

~~~
what-the-grump
Time value of money.

Technical debt it's literally dollars to donuts in time spent getting yourself
out of the hole you are in right now.

Maintenance is the cost of keeping the lights on.

I run a two year old system which is now riddled with technical debt. How we
got here has very little to do with the technology decision, stack, code, and
a lot to do with management outsourcing and cost cutting.

Technical debt is never paid back through maintenance. It's just
conceptionally wrong to tie them together. To phase better I can't maintenance
my self out of this problem, but I can keep this system running forever with
little to no cost.

------
ilikerashers
Having done building work in various guises over the years, I've seen is
interesting patterns analogous to software development.

Every builder comes in and says the previous guy didn't do it properly, used
the wrong materials and overcharged.

Every software project I've been on, someone always comes in and says there's
tons of technical debt, we're using the wrong language and the other
developers are poor.

There's probably some truth in both statements but it takes experience and
knowledge to take things with a pinch of salt.

~~~
xupybd
Did you make the switch from software to building? If so why?

Edit. This is genuine curiosity. I've made a slide out of software development
into a more hands on role. I've found it rewarding.

~~~
ilikerashers
I just have building projects in a couple of rental properties and my own.
Good luck in your building career, it sounds like the "Office Space" story!

------
cjfd
I completely get where this person is coming from. The distinction between
maintenance and producing new features on one side and paying down technical
is so strange. It does not make very much sense to start working on a piece of
the code that is hardly every touched and that has been working for years to
improve it. What one should be doing instead is to make sure that the work one
is doing for the purpose of maintenance and creating new features leaves the
code base in a better state than it was found in. If one does that it becomes
mostly unnecessary to talk about technical debt.

I do think technical debt does exist, though. Sometimes the changes that one
wants to do are a bit too big to do right now and one should make a plan to
get them done eventually and in small pieces wherever possible. This is called
having architectural goals. One should try to be in this situation as little
as possible, though.

------
jasode
_> Software do not have a technical debt problem, software simply requires
maintenance. [...] There is no such thing as technical debt. There is work to
do, that we can agree on, but it’s not debt payment._

The "technical debt" doesn't have a 100% universal agreement on what it means
and apparently the author has only been exposed to one variation of it and
that's what he's rebutting.

Another type of "debt" is caused by programmers writing bad/clunky code (often
_deliberately_ ) to quickly solve a problem. The wikipedia article mostly
talks about this definition of "debt"[1]. The programmers _know_ the bad code
will create "debt" that makes future maintenance harder. Example of this
tension would be 2 different approaches to adding a feature or bug fix:

\- (1) study the code base carefully -- maybe for hours or days -- and then
write the properly architected code that makes _future changes /extensions
easy_. E.g. expend the extra brainpower to see if the multiple edge cases or
logic spread across files can be unified or simplified.

... or ...

\- (2) quickly find the points in source code that seem "obvious" to modify
just change it -- sometimes _copy-pasting code_ and _duplicating logic if if
/then/else or switch/case statements_ in multiple files. Yes, now the
immediate issue is "fixed" but you've simultaneously created "debt" down the
road.

[1]
[https://en.wikipedia.org/wiki/Technical_debt](https://en.wikipedia.org/wiki/Technical_debt)

first sentence: Technical debt (also known as design debt[1] or code debt, but
can be also related to other technical endeavors) is a concept in software
development that reflects the implied cost of additional rework caused by
choosing an easy (limited) solution now instead of using a better approach
that would take longer.[2]

------
tsechin
Calling tech debt maintenance seems a little odd.

I've always understood tech debt to be the shortcuts we take along the way to
ship fast(er). A global variable here, a hardcoded constant there, that copy-
pasted-slightly-modified function instead of adding a parameter.

Fixing those things seems qualitatively different from the maintenance
examples.

------
OldHand2018
Where I work, "technical debt" is a term used by the project management folks
whenever they are looking for justification for forcing developers to do
something that everyone knows is a bad idea.

No worries, we'll come back to it when we have more time (we never have more
time).

~~~
Viliam1234
> No worries, we'll come back to it when we have more time (we never have more
> time).

There are only two priorities: priority one, and priority "we will actually
never do this, because always something else will be priority one".

But of course, if it makes the engineers happy, we can put "fixing technical
debt" in Jira, and assign it any priority between 2 and 99.

------
firstbabylonian
I agree with this. 'Technical debt' always exists in the heads of the
engineers: the rest of the organisation can't see it. It's an invisible
problem, imagined by the engineers, and not always in touch with the practical
long-term reality.

Software is a tool. Tools that are used often require maintenance, which in
itself is not a novel concept.

Whereas saying 'technical debt' is like delivering a dramatically vague House
MD diagnosis.

If you must, call it what it is – Maintenance – and let's move on.

~~~
ggreer
> Software is a tool. Tools that are used often require maintenance, which in
> itself is not a novel concept.

Yes software is a tool, but unlike physical tools, it does not wear out.
Running the same code many times won't cause it to slowly degrade.

What does happen with software is that as you adapt it to particular roles, if
you're not careful you can make it very hard to re-adapt to new roles. A "new
role" doesn't necessarily mean user-facing features. It can be as simple as
running on Ubuntu instead of running on RHEL. Or it can involve using a newer
(and incompatible) version of some library. It might even be as daunting as
porting the software to a new language (eg: from JavaScript to TypeScript).

The common analogy used to illustrate this is that of a car. If you have a
typical passenger car and you need to compete in a demolition derby, you can
modify that car to be a good demolition derby car. But if you're then asked to
modify that car to win a track race, you'll have an easier time starting with
a new unmodified passenger car than modifying your demolition derby car.

------
mrphoebs
The distinction between maintenance and Tech Debt comes down to whether the
choice for an imperfect or expedient way of solving the problem was made
consciously. You incur Tech Debt consciously to deliver value in the short
term at the cost of not being able to sustainably deliver that value as
parameters change.

Maintenance on the other hand is stewardship of a system as both the
system(entropic decay) and it's environment constantly change.

~~~
spookylukey
I found Martin Fowler's "Technical Debt Quadrant" helpful on this -
[https://martinfowler.com/bliki/TechnicalDebtQuadrant.html](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)
. He argues you can have deliberate and inadvertent debt, both of which can be
wise or unwise - the debt metaphor still works.

------
jpswade
Technical debt is just business debt, it’s risk to the business if people
don’t understand it or it’s hard to maintain.

Technical debt is a terrible term because it implies it’s just a technical
problem, but it’s a business decision.

~~~
juniper_strong
It's a terrible term because the technical people think they are talking to
the business people in their terms, but when the business side of the
operation hears the term technical debt, they ask some questions and what they
hear is that they are issuing non-recourse debt.

What the technical side of the operation wants to say is "We're making short
term decision that are going to hurt us in the long term", and what the
business side of the operation hears is "This is free money".

------
choeger
Technical debt is _not_ maintenance. Except for a very radical perspective:
"So you used python2 in 2008 to start your project? Well you obviously knew
the language would not last forever, you should have chosen ANSI C99 instead."
This argument can be made for any dependency and it contains a grain of truth,
but generally it is just too extreme.

------
alxlaz
I sympathize with the author's take that our industry is way too trigger-happy
and willing to throw away perfectly working code, but none of this:

> Python 3 changed all the string handling, have to make adjustments. The
> build is too slow, should make it faster. Security vulnerability found in
> one library, time to update libraries.

is what (most?) people mean by technical debt.

If the build is just slow, but can be improved, that's not technical debt.
Technical debt is when the build system is actually a bash script that was
written ten years ago because none of the developers wanted to waste time on a
proper makefile, and none of the interns knew make (or cmake, or ant, or
whatever), and now just _adding_ a new source file takes three hours.

(Edit: oh, or my favourite example, how could I forget this?

I've worked on a very large (MLoC) codebase that used autotools as a build
system. Unfortunately, at some point, someone didn't want to learn m4 --
totally understandable -- and committed a manually-mangled configure script
and a bunch of generated makefiles...

...and from that point, autotools were eschewed completely, and the configure
script, and the generated makefiles, had mangled by hand each time something
was required. Adding a new module to that program took 2-3 days of grepping
and hunting through a bunch of files, just to make sure you didn't miss
anything. That's more than enough time to learn the basics of how to use
autotools. Multiply it by several _hundred_ modules and weep.)

If a security vulnerability is found in a library, and that's solved with a
library update, that's not technical debt. Technical debt is when message
signing is done via MD5 hashes produced by a slightly buggy in-house
implementation. You got to ship on time, but not by shipping a functional
product -- that's a bug, and it still has to be fixed at some point.

If some stuff is single-threaded and slow, but easy enough to parallelize so
that it's faster, that's not technical debt. Technical debt is when there's a
single, global object containing absolutely all application state, and
splitting an extra thread to do some computation in the background requires
four weeks of extra manual testing just to be sure you didn't introduce
_another_ race condition.

(Edit: unfortunately, nope, none of the examples above were invented. I had
the pleasure of working on a codebase where adding a new thread literally
required written approval from the product manager because of the extra
testing it required. Calling that "maintenance" is much like calling a bridge
collapse a "vertical position readjustment" \-- it gleefully ignores the fact
that it was readjusted downwards, through gravity, possibly involving mass
casualties, and had to be rebuilt).

Some maintenance work is legitimate and is just the result of normal software
progress. But _some_ maintenance work is entirely self-inflicted. Ignoring
that is just an excuse for the kind of "first we do git push, then we think
about it" crunch mentality that lots of companies encourage, for reasons that
have absolutely nothing to do with either productivity or technical
excellence.

~~~
user5994461
Joking aside, they should have "maintained" they build system before it took 3
hours to do a build.

Things don't go from 1 minute to 3 hours overnight. The company and the
developers had to work with it daily and didn't bother to take care of it at
any point over 10 years. It's not a technical problem as much as it was an
organizational and human problem. Inertia does add though so that's certainly
difficult technically to replace now and getting more difficult by the day.

------
sixstringtheory
Technical debt is not maintenance.

Technical debt is the additional maintenance for which you create a need when,
presented with multiple options to implement a thing, you take the quickest
and dirtiest one. It compounds the more you make decisions like that, just as
compounding interest and capitalization create ever higher amounts of monetary
debt.

Also, I found their self-referenced article on how Windows required more work
than the pyramids, using man hours as a metric, simply absurd. This strikes me
as a mythical man month type fallacy but can’t quite put my finger on it.

------
jankotek
> To make another analogy, when you bring your car to the mechanic to replace
> breaks after 80 000 kilometers, he doesn't proceed to warn that the previous
> mechanics has left debt'ed break pads all over the place and to question the
> person's qualifications.

Good mechanic will refuse to touch your car. If breaks would fail after her
fix, she might be liable.

Same apply to coders. If your code is bad, it will be very difficult to find
good developer to fix it.

------
bencollier49
It feels to me as though this argument misses the point.

\-- Technical debt is time that you have borrowed from the future. --

That makes perfectly good sense if you need a simple, working system, quickly.

But if you plan on extending it, then the workarounds and shortcuts that you
took will need to be replaced, slowing you down in future. Concrete classes
where abstractions will be needed in future, hard-coded values, all that
stuff. The debt will have to be repaid.

------
ChrisMarshallNY
_> This is meant literally. Reading existing code is difficult -more difficult
than writing code- thus it is a genuine take from the developer that throwing
everything away and starting over from scratch is “easier” than continuing on
the existing. [Ergo this is flawed for non-small projects because the new
development will never catch up with the existing during the tenure of the
developer(s).]_

I tend to work alone, so the poor schlub that needs to go in and maintain the
code is usually Yours Truly.

That’s a big reason that I am pretty obsessed with heavily-documented code. I
eat my own dog food.

It is quite painful to review undocumented codebases; even (especially) really
well-written code. I write in Swift, and it’s entirely possible for an
experienced Swift programmer to write highly efficient code that is almost
completely inscrutable.

Not sure I’d necessarily call that “technical debt,” but it’s a real issue.

I’ve learned to use naive coding (in reality, highly efficient code often
doesn’t buy squat), and a lot of “this is why I did this” commenting, along
with long, descriptive entity names[0]; assuming that it’s my goal for my code
to be maintained by others, and to not have them constantly pinging me with
questions.

I will say that the (fairly ambitious) projects I’ve done that have grown into
large community efforts, have resulted in very, very few questions about the
code. It seems that understanding the code I write, isn’t an issue, for most
people.

I write code for myself, and that seems to make others happy.

[0] [https://medium.com/chrismarshallny/leaving-a-
legacy-1c2ddb0c...](https://medium.com/chrismarshallny/leaving-a-
legacy-1c2ddb0c8014)

------
pdimitar
Pretty low-quality flaming post. Basically "battle of the word definitions".

Refactoring is observably the best way to get to know someone's code.
Refactoring doesn't have to actually change behaviour; in fact, the word
itself means "improving the code without changing its behaviour".

Not seeing any value in this post outside of "I disagree with some words,
let's use others".

~~~
Cthulhu_
This is what I've caught myself doing; instead of reading and trying to
understand the code, I scan it and start "fixing" it to make it my own.

Writing and changing code is a lot less boring than just reading it. Focusing
on details (formatting, function naming, ordering, files) seems to be a lot
more "gratifying" than trying to grasp the bigger picture.

I guess this is why I'll never become a senior developer / architect. Mind
you, atm I don't have anyone else working on the same codebase either so it's
all me.

~~~
pdimitar
What's a senior developer? I had zero problems grasping a lot of bigger
pictures but since I didn't care much about political and office drama I never
was dubbed "senior" while working in offices.

At one point I decided for myself that I am senior by the virtue of being able
to quickly understand what's happening in a codebase and where the real value-
add lies, plus the ability to integrate it into the bigger ecosystem of
deployments that the company practices. And having a good general culture.

So don't you care about "senior". :)

As for the topic -- harmless refactoring is indeed the way to get to know
code. This has been said by people like Martin Fowler and Kent Beck so it's
not exactly baseless and isn't easily refutable by a flaming post like the OP.

------
ZiiS
Whilst I am sure Debt exists in classic software it is endemic in SaaS. If the
truck is travelling at highway speed and you cannot afford to pull over;
changing the break pads can indeed cost considerably more then building a new
truck.

------
karmakaze
This is all just words and redefinitions, how you choose to slice and label
things. Here's the useless reframing:

> Software do not have a technical debt problem, software simply requires
> maintenance.

Despite the words used, tech debt does exist. This article doesn't do much to
make the task of maintaining software any better. It lumps it all together.

Tech debt, created accidentally or purposefully can be reduced with specific
forms of maintenance which makes further changes easier and reducing future
maintenance efforts.

------
ggm
The principle force of the analogy is the compound interest equivalent cost of
delayed update. Jumping over versions can acquire more bugs than you can
handle and the cost of remediation en masse under time duress is not the same
amortised time as the per increment bugfixing across the versions

I have experienced this and I also work with people who deny it. It's
complicated.

------
websitescenes
Technical debt != maintenance.. Maintenance is just maintenance. Technical
debt is having to jump through arbitrary hoops to satisfy a code base or piece
of technology instead of being able to directly address the problem at hand.
With that said, I do agree that all code has some degree of technical debt but
that can be limited by good design.

------
IceDane
What a vapid, shallow and uninteresting article. Congratulations, you just
gave technical debt another name. That doesn't mean it doesn't exist.

Maybe you should try reading up on the subject matter next time before writing
a blog post so you don't end up rediscovering fire again.

------
Fire-Dragon-DoL
I think the point might be the term? I read somewhere a suggested alternative:
product debt. The technical side is the one that loaned the time in terms if
shortcut. Paying it back has always a steeper cost.

Not only that, it also compounds.

------
grafelic
To me (from an Ops perspective), technical debt is when people who have come
before you implemented a setup that is broken at a deep level. A setup which
can only be fixed by a complete re-implementation. No amount of maintenance
will suffice.

------
rdiddly
I like the debt metaphor, especially because of 1) interest, which costs more
the more debt there is and the longer you carry it, and 2) the fact that
sometimes it's smarter to borrow than to be debt free.

------
jjn2009
If someone is knowingly building something that wont scale is that not an
accumulation of future work? I think the key point about technical debt is
that units of work are not all equal in long term outcomes.

------
prashnts
No it does. You make a point before bikeshedding.

------
xupybd
It does exist in the form of libraries and language versions that slowly get
dropped from modern eco systems.

Each dependency adds a little more debt.

------
amelius
Is "technical debt" a term used more by business people/managers or by
developers?

~~~
rablackburn
Personally I (a developer) use it most as a metaphor for business people
explaining why we need to schedule time in-sprint for work that isn't
explicitly tied to a new feature.

We have debt, we need to service it. Repayments come in the form of developer
time. If our debt is well-serviced it enables us to keep up a nice quick pace
of feature development.

If a feature is politically important and our tech-debt is under control we
can fast-track its implementation knowing that we'll have time to polish it up
later and it isn't likely to break too much.

If our debt is too high we can't borrow anymore. Sorry, that super important
feature that the board wants by end of sprint simply can't be done. We're at
our credit limit and if we try and borrow more to get that done we'll go
bankrupt (the product crashes and burns).

All of this is the language of business

------
ekvilibrist
So there's no bad code, no poorly designed systems? Only "maintenance"?

~~~
preordained
If the code was initially a net positive (i.e. provided a feature users
wanted/needed, etc.), then in a way, yes. It might be bad in the abstract in
the way patching something with bubblegum is, but if it works at the time--it
works.

I think the only way to argue it was wholesale bad is that it immediately and
objectively sank future progress (like a fatal wound of sorts). If it made
things a hassle going forward, you'd have to argue that it was so much of a
hassle that it actually receded things back into a negative. Most companies
rarely experience the debt that stops forward progress cold or can prove
they'd be making X times more progress if wasn't for such and such debt.

That said, if you could do things in such a way that yields the desired result
and causes less (there is always some, and never little) maintenance, that's
ideal. The thing is, everyone is trying to code from that place. The only ones
who aren't are those who can't (they really are incompetent) or those who have
given into utter malaise or malice.

------
cloudhead
Complete nonsense..

