Ask HN: What's the worst kind of technical debt?
12 comments
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.
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.
- https://docs.sonarqube.org/plugins/servlet/mobile?contentId=...
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.
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.
The link requires a login to view
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)
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)
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.
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.
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.
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.
[deleted]
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.
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.
Overengineering. You can always refine chaotic code, but cutting down and simplifying abstract code can be almost impossible.
Long workflows.
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