Fabio Colasanti

Technical Debt is slippery, no doubt about it.

Its very definition often misunderstood; its formal quantification elusive; its
causes/effects all too frequently brandished as the ultimate weapons of blame
allocation (or indeed self-justification). Perhaps it's time we stop a second
and actually take the time to understand what Technical Debt is, how it
typically manifests itself, and reflect on viable, sustainable strategies to
control it. In fact, by the end of this post, I will indeed argue the case for
its rehabilitation.

As a short preamble to the problem space, I need to introduce the notion of
conflicting interests. Far from me subscribing to the toxic notion of Product
Team vs Technical Team, it must be recognised though that in any sizable
endeavor (especially at enterprise level) there are different interests,
concerns, roles and responsibilities within the delivery team. I'll spare
everyone the obvious paragraph about technically savvy POs/PMs, commercially
astute technical architects and business focussed developers... how they
actually exist and how can all work together in harmony. What I'm interested in
here is to define two groups of interests (not people) which I'll lazily call 
Product Interests (PI) and Technology Interests (TI). Each one embodies
different and sometime conflicting needs, aspirations, drivers and objectives.


What it is and how it comes about
The expression "Technical Debt" stems from an analogy with the financial loans
market, first attributed to Ward Cunningham
[https://www.youtube.com/watch?v=pqeJFYwnkjE] in the early 1990's. Put simply,
producing and shipping artefacts of sub-optimal quality is the equivalent of
contracting a debt: opportunities are levereged, the immediate cost is deferred
on a promise of repayment, and interest become payable until settlement. In the
analogy, interest are constituted by a cumulative decreased agility of
intervention, and the principal repayment equals to the replacement of the
temporary, sub-par solution with a better one.

Access to credit enables the realisation of opportunities otherwise
unattainable. As such, it is crucial to recognise that Technical Debt is a
choice dictated by the pursuit of an advantage, as part of the execution of a
precise strategy. It has very little to do with a set of malpractices that are
often conflated in the mainstream notion of Technical Debt: missing
documentation, scarce test coverage, non-existing refactoring, lack of basic
standards, and general disinterest in quality have more to do with poor
technical craftsmanship than with the gain of advantage through deferral of
costs. These are part of core TI's concerns, and a zero-tolerance policy can be
an appropriate: developers are expected to carry these out without PI's prompt,
authorisation, or sign-off on a backlog ticket.
Equally, there are examples of reckless ingerence of PI in TI (eg
vendor/technology selection, refusal to innovate, distrust in industry best
practices, distrust in experts, etc..), that shouldn't be classed as Technical
Debt either. Causes for this sort of idiosyncrasies are rooted way deeper in the
fabric of the organisation and are beyond the topics of this post.

Technical debt is a choice commonly associated to a lack of time, resources,
experience, or knowledge - in pretty much any combination.
In the age of Agile and Lean delivery, it's not infrequent for TI to have a
stake in the fast release of features with the main purpose of acquiring
precious feedback from both the users and the surrounding environment. Proof Of
Concepts are prime examples of this. Iterative processes inheritedly carry some
degree of redundancy which is accepted by PI, but in itself represent
progressive enhancement of a solution that is initially sub-optimal. As new
learnings are acquired, experience will contribute to better designs for the
next iteration and faster shipment of better products.

Most often though, Technical Debt is associated with a different scenario. In
order to keep up with changing market conditions and new customers demands, take
full advantages of windows of opportunities, or even gain first mover advantage
(all very typical PIs), ambitious delivery schedules are set, and these soon
become the root cause of shortcuts and sub-optimal solutions. The choice to
contract a Technical Debt is both explicit and often understandable.
Unfortunately, running interest and total debt are often neither acknowledged
nor honoured with the same determination, giving way to the undesirable side
effects most commonly associated with Technical Debt.


The effects
Whilst increased speed of delivery, associated learnings and market advantages
are all arguments in favour of a responsible Technical Debt strategy, when badly
executed it can have catastrophic effects on an enterprise. Just like financial
debt, accumulation of unconsolidated debt can bring companies to their knees:
the weight of interest as a self-inflicted handicap on the ability to adjust and
evolve, has the potential of bringing organisations into a deadlock of forced
stasis. There are countless examples of badly managed Technical Debt that,
blinded by the short term advantages, have neglected its management resulting in
lengthy and costly next iterations, innovation more and more difficult to
implement, PI and TI engaging in open conflict with mutual allocation of
responsibility, and people losing enthusiasm, interest, and ultimately jumping
ship.

Like productivity and total cost of ownership, Technical Debt too suffers the
undeniable difficulty of quantifying it. The loan analogy comes comes all but
short here: how do you measure exactly how much is due and by when, what the
interest rate is, and whether in mutating conditions the borrowed capital is
ever repaid at all.

Interestingly, when it's in both the TI and PI advantage of cutting corners,
there's often an implicit understanding of the boundaries of the Technical Debt
extent, its duration and repayment terms. It's probably this very alignment of
intents and objectives that have made "alpha versions" and "first iterations"
slip through the nets of Technical Debt classification.
There is therefore a strong argument for this very aspect to become the first
ingredient in the recipe for Technical Debt management.


Managing Technical Debt
Share objectives and motivations
All too often the tension between PI and TI stems from the former calling the
shots and the latter being at the receiving end (frequently being left to mop up
the resulting mess too). It's not by chance that in highly cohesive teams where
PO/PM are deeply embedded in the development team and technologists are involved
in commercial strategy, Technical Debt is virtually not-existent. Or rather its
perception is. The same hard choices are made and some degree of shortcuts
become accepted because it's the team as a whole that has a stake in it.

Call it, own it
For effective accountability to be enforced, it is necessary to openly recognise
Technical Debt and explicitly own it. Something as simple as a registry can have
a massive positive impact on the perception of the debt, and the credibility of
the borrower.

Stay on top of it
We already discussed how effective measurement of Technical Debt can be
challenging, but so are many other indicators for which frameworks and
methodologies have been put in place (productivity, velocity, cost of ownership,
cost of change, etc..). Once recognised and owned, it should be easier to openly
refer to it as any other aspect of product delivery. Time must be allocated to
the restitution of borrowed capital in the same way we would commit to a
mortgage repayment plan. It just something that needs budgeting for, it's part
of a delivery strategy, and as such must be managed openly and consciously.

Don't borrow beyond your means
When contracting a debt to enable immediate advantage, a longer term view must
be held to assess our capacity to sustain the debt (and its interest). Technical
Debt inevitably implies a loss of agility in implementing changes: innovation
becomes harder, lengthier and more costly. The temptation to face these
challenges through additional borrowing can lead to disastrous outcomes:
organisations becoming slaves of their own inability to evolve with the changing
market conditions, every adjustment so costly that there's no room for error
(hence for learning), compounding the problem of stiffness one round of
borrowing after the other.

Pay back, and make a big deal of it
Countless example of irresponsible borrowing and missed repayments have dented
the credibility of loanees to the point where perfectly sensible strategies are
hidden away from the team, in the implicit assumption that they would be
misunderstood, undermined, and rejected. It's almost like a long string of
written-off debts have led to the average delivery manager having a terribly
poor (assumed) credit score.
Every time Technical Debt is duly repaid, it should be recognised, celebrated
and shouted out as loudly as possible. At least until it becomes the norm.


Conclusions
Too long a string of failed executions has already twisted the very definition
of Technical Debt, confusing the perception of undesiderable (but avoidable)
outcomes with its original intent as enabler. Tech Debt must be treated as a
strategy in itself - not a synonym of failed strategy as is typically the case.

Technical Debt is ultimately a problem of trust. Incurring Technical Debt is a
perfectly viable, sustainable practice that can lead to competitive advantage,
but it's vital for trust to be won back through open ownership, accountability
and timely repayment.

Enterprise Architecture

Enterprise Architecture Blog Posts