- Debt by negligence
This is the everyday accumulation of technical debt in a project. It's the little things that can really add up over time. Examples of this include...
- Leaving code in giant indecipherable methods.
- Not giving variables meaningful names.
- Bloating an existing class.
- Leaving in commented out code.
- Not giving meaningful commit messages.
- Failing to write or update unit tests.
- Debt by constraints
The best of intentions and due diligence among the developers won't matter if there's too much being asked of them. Examples of this include...
- The amount of work cannot be achieved in the time allotted.
- The developers with the wrong skill-set are assigned to the project.
- Interference in the process from management.
- The technology stack is less than optimal for the solution.
- The requirements repeatedly shift.
- Debt by investment
There is the very rare occasion that taking on technical debt is the wise decision. Examples of this include...
- Responding to an urgent deadline.
- Getting a prototype up and running quickly.
Not all technical debt is bad, and some kinds of technical debt are more or less benign in the scheme of things, but it's worth recognising what factors lead to technical debt, so that the decision to address it can be a informed and deliberate one.
Sometimes we should know better, sometimes we can't do anything about it, and sometimes it's worth it.