Ask HN: What's the worst kind of technical debt? - piinbinary
======
malux85
The death of 1000 cuts - the code base that has had corners cut 1000 times,
each time getting progressively worse and worse, until it's so fragile, that
even tiny modifications have drastic and unpredictable outcomes.

Global state being modified by race conditions. Over abstractions doing
nothing but piling on the call stack. Interfaces ill defined and so there's
lots of type casting and copying. Shudder

------
sophe
The worst kind of tech debt is _test_ debt: the huge body of unidentified and
undiscussed tests that never get considered. On an "agile" team where there
are no test specialists, and the emphasis is on CI/CD with fully automated
tests, those tests are confirmational: these tests verify that the code works
as expected, and they have to run fast. If you have an SDET, then their work
is most likely focused on tooling to improve the efficiency of the dev team,
and _not_ to exploring and learning about the applications to drive quality.
This is delivering "working code" with eyes closed and fingers crossed, and
this test debt hangs like the Sword of Damocles above your company's
customers.

The role of test specialists is to try and make the unknown unknowns a little
less unknown. If you have decided that it's finally time to hire a test
specialist, then you have that huge test debt PLUS immediate pressure to focus
on new features.

------
mlthoughts2018
\-
[https://docs.sonarqube.org/plugins/servlet/mobile?contentId=...](https://docs.sonarqube.org/plugins/servlet/mobile?contentId=11636640#content/view/11636640)

The worst tech debt is whatever is making the current quality leaks worse,
generally whatever is being changed or added right now, usually in a hurry
because someone shortsightedly thinks it’s business-critical to prioritize
speed of delivery above quality standards.

Maybe they are right, maybe they are wrong, but either way whatever they are
asking you to break in order to get it done sooner, that is the worst thing
going on.

The more effort you spend focusing on making that process leak proof, the less
future puddle there will be, leaving time to clean up the existing puddle.

No matter what tech debt there is in older, not-currently-changing-due-to-
project-needs code, it is like the puddle, maybe a large puddle, but it is not
the leak.

~~~
shoo
to attempt to reword what you're saying:

the worst kind of tech debt is the kind that grows over time (perhaps as
people interact with the system and continue to make changes to it)

~~~
mlthoughts2018
I’m not sure if I would say that. Maybe we’re saying the same thing, but I
would characterize it more by saying the worst tech debt is whatever is
allowing new tech debt in code today.

I think it’s specifically that the worst tech debt is whatever tech debt you
are adding at the moment, whatever is changing in the code right now.

It’s the leak vs. puddle analogy. Stopping the leak allows you to stop letting
new tech debt get in, regardless of whether existing tech debt is a growing
puddle.

For example, when thinking about what tech debt to fix, a mistake I think
people make is to focus on a big “systemic” piece of old tech debt that seems
to grow because it affects new things and forces you to code around it or
something.

But the project has self-evidently been living with that tech debt already. It
can be managed. In the meantime if some relatively harmless seeming tech debt
continues to creep in through code reviews, _that’s_ a worse problem, even if
it’s not “growing over time” in the manner of a long-lived wart in the system.

------
simonhfrost
Tech debt created from old business decisions.

You want to know why we added the isPancake method? You'll have to ask Lucy
who's back from holiday in two weeks, who mentioned talking to Greg the intern
from last summer, who said his old manager Anna said it's very important.

Please don't modify it until you've done that.

------
becga
Agree with the tests tech debt comment. Another huge problem is organizing
deployments and environment configs in general for those shops not using
something like k8s etc.

------
thijsvandien
The kind that keeps growing. Any mess can be cleaned up given time and effort,
but if more mess is produced faster than it can be cleaned up, it's a lost
cause.

------
bjourne
Overengineering. You can always refine chaotic code, but cutting down and
simplifying abstract code can be almost impossible.

------
gt2
Long workflows.

