Friday, September 30, 2016

Kinds of Technical Debt

I think there are three main ways technical debt accumulates. They are:
  1. 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.
    All of these are entirely avoidable if a programming team is taking care with what they do. Unless the code is finalised, and the system works so well that no maintenance is ever needed, these practices will hurt the project later on.

  2. 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.
    These debts are often the most easy to recognise, but the most lamented by developers. It can be an excuse for why a system ends up a fragile kludge, but not an excuse for throwing away good practices.

  3. 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.
    In these cases, the technical debt should be acknowledged and paid down as soon as possible.

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.

No comments:

Post a Comment