Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Calling this tech debt stretches the metaphor too much. We're missing terms for this common kind of problem.

"We decided not to FOO" is already called tech debt.

Say "we MUST BAR but never planned for it" is an Oops.

And "SQUISH lacks any sense of consistency or intentionality" is a SNAFU.

And a "we don't all even have common language to talk about what we need to do" is a Whoopsie.

Then maybe we can also introduce sparkline graphs to help us visualize the effort needed to overcome it all: the Whoopsie-Doodle.



Thanks, I feel that “Tech Debt” is an abused term to make mistakes sound like they’re not mistakes but something else to evade responsibility.

If you fucked up, that’s not technical debt. If business requirements change, you don’t have technical debt

Calling every problem or challenge technical debt is so unhelpful and frankly a bit dishonest too.


Process debt is another one I've invariably come across and covers the need for loose requirements (especially early on).

There's a lot of technical debt that's going to accrue before the process debt is sorted if you're trying to scale quickly.


If you build with the explicit goal to learn and explore the process and problem domain, and then have to rework code because of new insights and understanding, we are as close to the original definition of technical debt.

But it is my impression that this is the rare exception. In most cases, people are just bullshitting to cover up their ineptitude.


I tend to use "tech debt" as a euphemism for other people's bad code and design decisions. Work politics.


Ha, I think that’s the most legit usage of the term.


I think these others still lead to "tech debt" when you decide to ignore or divert the work.

>"SQUISH lacks any sense of consistency or intentionality"

And once you acknowledge the problem and decide not to address it, it's tech debt again.


I don't see that as disagreeing with the parent in the end. The key words are 'decide to', which the parent already used. Once you recognize a problem and decide not to deal with it, it's technical debt. You're avoiding paying for the problem for some reason. Perhaps you hope to never deal with it, or perhaps you think you can get better return on your (time/energy) investment working on something else first.

The point stands: Unforeseen problems aren't 'tech debt' in themselves. They become tech debt once they are recognized and not dealt with.


I like this. Here are a few more:

"We maintain a lot of BAZ we think no one needs anymore but we don't know for sure" is called a Yikes.

"You just have to know which alerts matter and which don't" is called an Uh-oh.

And of course "securing the QUUX wasn't an explicit requirement for launch so we haven't done it yet" is already called a vulnerability.


Agreed. Tech debt had a specific meaning of intentionally taking out a loan with a known larger payoff for investment in a known horizon.

The garbage crap dumpster fire of code at your company is not tech debt; it’s incompetence on display.


Just because your loan was a stupid one with terrible terms doesn't mean you're not in debt.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: