
Two Kinds of Tech Debt and How to Pay It Down - kylegalbraith
https://blog.kylegalbraith.com/2018/10/22/two-kinds-of-tech-debt-and-how-to-pay-it-down/
======
eagsalazar2
At my company we also always talk about two kinds of tech debt but in a
totally different way: (1) "bad" code debt is basically high interest where
the longer you wait the refactor story grows and grows and gets scarier and
scarier. (2) "good" is interest free or low interest debt which you should
defer paying as long as possible so you can focus on more important immediate
things. This is usually achievable when the thing you are ignoring can be
neatly encapsulated and doesn't affect the rest of your code as the codebase
grows and evolves.

Usually we talk about this distinction when deciding to defer work for
hypothetical scaling. For example we had an app that required HIPAA compliance
and had a chat feature, since we were initially deploying to a few hundred
users for a pilot and our main short term goals were about learning/validating
we just build it using polling since none of the other sockets based
alternatives were easily HIPAA compliant. It worked great for the pilot and
took like 2hrs to implement and because it was so simple we were able to
evolve the chat experience really quickly with different features as we got
feedback.

------
ErikAugust
One of the things about technical debt that I have seen is a lack of a real
accounting system that at least ballparks the costs in real dollars.

Countless acquisitions happen where technical due diligence is not performed,
and acquirers realize later on they have wildly underestimated the cost.

~~~
hinkley
And that's probably why this doesn't happen.

If you have bookkeeping that shows that you're a bad acquisition target you go
out of business and are considered a failure. If you don't then you get bought
by someone idealistic and you're considered something of a success.

~~~
ErikAugust
Sure - it’s something you can sweep under the rug by not having any
accountability on it.

~~~
hinkley
Yeah, I'm not saying I agree with it, I just comprehend how it happens.

------
tcopeland
Another scenario is when an acquisition occurs for the data a company has
collected and so the codebases are quietly retired. In that situation there's
still _some_ value in paying down _some_ technical debt - security updates on
libraries and whatnot - but there's a point at which the decommissioning
effort becomes the primary driver.

------
thaumaturgy
You can take advantage of the reusability part of software development to pay
down technical debt in a way that's impossible with traditional debt.

Developers and businesses should have a well-maintained toolbox, library, or
framework that they use for just about everything they work on. The longer you
use the same toolbox, the better the tools will get; just improve them a
little bit every time you use them and deploy those improvements to as many
projects as possible.

This gets hard to do in environments that are always chasing the new thing.

------
bryanrasmussen
missing the concept of tech depreciation, if your codebase has a debt of 2000
codedollars and a value of 10000 codedollars, those value codedollars are
probably depreciating over time and moving to the debt column.

------
andy_ppp
"There are two kinds of people in the world, those who believe there are two
kinds of people and those who don't."

\- Robert Benchley

EDIT: just to be clear I'm very skeptical there are only two kinds of
technical debt...

~~~
lthemick
> EDIT: just to be clear I'm very skeptical there are only two kinds of
> technical debt...

The author acknowledges this in the article:

    
    
      "Of course, there are more than two types of tech debt, but I think the two we talk about here cover a lot of ground."

