DEV Community

loading...

TFW You Realize What Technical Debt Actually Means

Kahlil Lechelt
JavaScript tings. Podcast Boi at reactive.audio. Nested Loops founding member. KarlsruheJS co-org.
・2 min read

A few weeks ago I set out to write a blog post about technical debt and the
complexities of getting rid of it, or some of it, when you work for a company.

I wanted to see what others had written about it and of course I landed on
Martin Fowler's article about technical debt.
When I started reading it I realized that up to that point I didn't really know
what tech debt was.

It seams that while being confronted with the eternal vastness of software
engineering, this is what my brain does: when I hear a term for the first time
and I can deduce its approximate meaning from context, I store it as a known
term. Even though I don't know exactly what it is.

What I deduced it to be was: "Legacy code, that makes it hard to maintain your
code or to add features."

And every time I heard or used the term "technical debt" there was a tiny little
voice in the back of my head going: "Why is it "debt"!? I don't get it."

Anyways good ol' Martin cleaned up that part of my brain and made it crystal
clear for me:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us
think about this problem. In this metaphor, doing things the quick and dirty
way sets us up with a technical debt, which is similar to a financial debt.

Like a financial debt, the technical debt incurs interest payments, which come
in the form of the extra effort that we have to do in future development
because of the quick and dirty design choice.

We can choose to continue paying the interest, or we can pay down the
principal by refactoring the quick and dirty design into the better design.
Although it costs to pay down the principal, we gain by reduced interest
payments in the future.

It's a metaphor! It is actually a term that was invented in order to explain
consequences of sloppy coding to people in suits!

Fowler goes on to write:

The metaphor also explains why it may be sensible to do the quick and dirty
approach. Just as a business incurs some debt to take advantage of a market
opportunity developers may incur technical debt to hit an important deadline.

The all too common problem is that development organizations let their debt
get out of control and spend most of their future development effort paying
crippling interest payments.

Thank. You. Technical debt can lead to crippling interest payments. These
can slow down your development teams so badly that you can't compete anymore.

The term "technical debt" carries all the information you need in order to make
the argument to company leadership why getting rid of it or keeping it at bay
may be a wise business decision.

Who knew?! 😂

Discussion (0)