A few thoughts on Technical Debt

What are you talking about ?

If you are part of a young, small startup, you may never have heard of technical debt. You you work in a big, established company, you may never got to hear about it as well.

And that, I’m afraid, is already a point.

Technical debt can be thought as “a measure of how much work would be needed to bring software environment, components or procedures to current state of the art”.

In other words, if you had to make it from scratch today, it would look different from what you actually have, right?
What would it take to get there not from scratch but from your current reality? That’s the debt we’re talking about. (And yes, “from scratch” may be cheaper than that)

Most businesses nowadays depend on software (and related procedures), even brick factories. That’s why, on purpose, I included all sort of “established companies” in my opening remarks.

Where does it come from ?

Many factors can originate this debt:

  • Implementation shortcuts have been taken (time to market, technical issues, laziness, …)
  • The chosen architecture has little or no flexibility (e.g. a monolithic system)
  • Custom solutions have been devised instead of exploiting standard protocols and design patterns
  • The component is called to perform well beyond the original perimeter and/or with very different goals/requirements
  • A much needed refactoring keeps getting postponed
  • There is little/no documentation (either explicit or embedded within code) for a complex system
  • The platform/technology just gets old and becomes obsolete
  • The process/procedure gets old and becomes obsolete (“We have always done it that way”)

and many further ones, I’m pretty sure.

Everybody does that, cannot be that bad, right ?

Technical debt is not a bad thing by itself, as current state of the art may not bring value to a specific need.

Negative effects can arise when debt keeps piling up over a (longer and longer) period time, and interests are to be paid just to stay afloat (yes, it’s really like a mortgage):

  • It becomes increasingly difficult to fix bugs and add features
  • Substantial work is needed just to maintain/improve performance
  • It takes a long time for a new team member to learn the ropes of the system and become productive, also costing a considerable training effort on senior member’s part

But this year’s budget is for new projects !

The (often) wrong perception that reducing technical debt has no Business Value leads to the debt itself to go unmanaged (or even unnoticed!) and increasing for a long time, up to a point when simply keeping the system or component in working order overwhelms the maintainer team.

That’s when Technical Debt turns into Technical Bankruptcy.

The system/component is then beyond improvement/refactoring and a whole new one is to be developed/setup from scratch, usually at a high cost (time is money, especially time of your best resources).

So are we supposed to stick to zero debt ?

Just to be clear: No :-)

As mentioned above, technical debt is not a bad thing by itself.

Likewise a mortgage from the bank, a technical debt can allow to reach goals (e.g. meeting a deadline, or an initial working solution) that would simply not be achievable otherwise.

The relevant points are clear awareness that a debt has been created, and constant focus on managing it (i.e., as a minimum, keeping it under control).

Awareness and management usually prove to be the real challenge.

Show your support

Clapping shows how much you appreciated Michele Bariani’s story.