Technical Debt is a well-known concept in software development. It reflects the implied cost of additional work which is caused by cutting corners, sacrificing quality for speed.
Some also add other aspects to this definition, such as the accumulation of weaknesses in a codebase as it grows and matures: architecture decisions that don’t quite fit anymore, haphazard workarounds (and then workarounds to workarounds, etc).
I’m frequently surprised that even experienced software engineers are unfamiliar with the term. They’re familiar with the concept, of course.
If only this were also the case with non-engineers. It’s frequently difficult to convey to e.g. management that this is in fact a real problem, and often a pressing one as well.
Just to be sure, technical debt, like debt in the real world, isn’t bad per se. Taken on judiciously it can be a valuable instrument. But just like in the real world, debts must be paid back with interest.
You better have a payment plan.
Martin Fowler has an insightful blog post from 2009 in which he sets up a diagram with technical debt quadrants:
Deliberate
+
|
|
|
|
| "We must ship it now
"We don't have time for design" | and deal with the
| consequences later"
|
|
|
|
|
|
Reckless | Prudent
+------------------------------------------------------------------------------------------+
|
|
|
|
|
|
"What's layering?" | "Now we know how
| we should have
| done it"
|
|
|
|
|
|
+
Inadvertent
You may be thinking that while this is certainly all true and interesting, where’s the connection to DevOps?
Well, DevOps organisations suffer from technical debt as well of course, except they suffer from it differently.
Because DevOps tries to incorporate the entire value stream, much mode debt becomes visible. To be sure, this debt was present before, but it was obscured by team boundaries, communications barriers, poor visibility.
Now that development and operations work together, be prepared for them spotting new issues, or becoming aware of something the “other side” had be plagued by for a long time.
In that sense, breaking down barriers may lead to painful revelations.
The good news is that this new way of working may also show new approaches for removing technical debt in easier, more effective ways than were visible before.
Maybe something that seemed insurmountable by the developers can with relative ease be dealt with in production, or the other way round.
But whatever the case: technical debt is just a fact of software development life. You do the best you can with incomplete knowledge, and as you continue your journey your knowledge invariably grows – so of course you’ll end up discovering what you now recognise as debt.
Don’t fight it. But deal with it, or it will come find you at the most inopportune moment.