Hacker News new | past | comments | ask | show | jobs | submit login

There are 2-3 definitions in there which make sense to me and could be conflated into one:

> when you make an engineering decision that makes sense at the time, but then conditions change, and the way you handled the tradeoffs makes less and less sense every day, and you need to change the system to be more in line with the current constraints.

> when you create Version 1 of a system very quickly, and this creates a business but not more jobs so that people can help you work on the system.

The other definitions might be used by people to obfuscate bad work, such as this one:

> when you build a system and about halfway through, realize that the architecture is not going to work, but you just keep going, and from that moment on, rather than call it regret, you call all your work technical debt.

Similar to the last definitions:

> when you don’t like the way something works and want to change it for good reasons and are asked to explain it, and you use all the usual metaphors like system upgrades or migrations or legacy migration

This one even gives examples of misusing other terms.

So the next article will be about the word "migrations"?

If this happens frequently, this is an organizational problem.

People should use words in good faith and knowing what they mean.

---

I have no doubt that there are people talking like this but every term like this can be misused.

IMO, "technical debt" is a useful categorization for tasks.

Involving multiple team members when categorizing tasks might help to avoid weaponizing terms like "technical debt" in an unfounded way to impose subjective preferences.

That being said, not caring about actual technical debt is still a very prevalent problem, so this article seems a bit fluffy to me, arguing against strawmen.




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

Search: