Technical debt and technical burden
One of the creative differences I often discuss with software teams is the distinction between technical debt and technical burden. You’ll be familiar with the first term, but I’ll review it here anyway. The second term - technical burden - is one that I use (perhaps I coined it) for a pattern of development often overlooked as a strategic choice.
Technical debt
Technical debt is a metaphor introduced by Ward Cunningham to describe the cost of additional rework caused by choosing a quick and easy solution now instead of using a more thorough approach that would take longer. Technical debt also refers to the backlog of maintenance or refactoring tasks on existing code which results from this approach. Taking on Technical Debt enables software vendors to move quickly and respond to new market or customer needs.
In this way, technical debt is like financial debt: both enable you to achieve now what you otherwise could not, but both require a long-term strategy be used effectively and not just expediently.
Technical debt has some additional complications because sometimes it is not accrued deliberately - bad design, rash management and poor quality-control can all lead to technical debt as a form of failure rather than a beneficial compromise.
Shipping is the most important feature
Yet it may be poor strategy to have no technical debt. The old product manager’s dictum Shipping is the most important feature emphasises the importance of getting your product out of the door. Yet we all know that we cannot ship perfect products. The biggest problem with taking on too much technical debt is that it does require maintenance and remediation. When done correctly developers should revisit through their code fixing issues they missed or couldn’t squeeze in before the release ended. This is inevitably more expensive than if those improvements had been made upfront. With too much technical debt, the remediation at some point in the future gets in the way of other new work - you are borrowing from future work. Unless you then take on more technical debt!
A well-balanced strategy allows for a product to ship with known debt, but also for a team to grow in capacity so that in the future technical debt can be remediated *and* new features shipped.
Technical Burden
Technical Burden is the responsibility you take on, by committing to a dependency or a capability not critical to your core product vision, but which you then must support in every future release.
An example. In 2018, MongoDB 4.0 shipped with some initial support for multi-document transactions with ACID data integrity. This was a feature requested from the community, but which MongoDB had to some extent resisted. The reason we didn’t need this is because the document model negates the need for ACID transactions, said MongoDB founder Eliot Horowitz.
Grigori Melnik, VP of Server said, Because of this fundamental difference in data modeling, MongoDB’s existing atomicity guarantees can meet the data integrity needs of most applications … In fact, we estimate 80%-90% of applications don’t need multi-document transactions at all.
So, MongoDB chose to ship a feature requiring three years for the first release for only a small minority of use cases! And this is feature which they now must continue to support. The demands and dependencies must be factored into every design decision of the MongoDB engine.
As it happens, they also shipped with considerable technical debt. The blog post from Eliot Horowitz explains that rather well.
I know this sounds very disapproving of me, but I do understand the logic. MongoDB were excluded from some scenarios because of lack of full ACID support. I know from salespeople that they were often excluded from RFPs because they could not check that box, even though the scenario could (as Melnik describes) be met with MongoDB’s existing data integrity features.
Nevertheless, this is a form of technical burden. It was knowingly taken on, no doubt after much debate and planning. But as you can imagine not all technical burden is so carefully considered.
Assessing technical debt and burden
Here are six challenges you can use to assess the cost of technical debt and burden to a software team.
Is it deliberate or inadvertent?
Has it been costed?
Is there a plan to address it?
Is it time-critical or resource-critical now?
Can it become time-critical or resource-critical?
Will success make it worse?
The last one may seem curious, but just imagine if you release a deliberately compromised feature, or you take on a specific burden … and it becomes popular! Now you may need to throw in even more resources than ever before to remediate the debt or to continue to support a burden which was never central to your product vision.
To assess the value of debt and burden, some slightly different challenges:
What advantages have been gained in getting to market while carrying technical debt?
What interest is being paid in the form workarounds and inefficiencies?
What is the opportunity cost of fixing the debt in the future? (What will you not be able to do, because you must remediate the debt?)
What are the implications if the debt is never fixed?
What is the additional market value of features which impose technical burden?
Is the burden required for marketability but not for technical needs?
Is the burden just made up of additional features? (So … not really a burden, perhaps)
I hear a lot about technical debt in conversations with engineers. But technical burden can be just as onerous. It’s worth looking at your plans for both.