Life of the counterparty: tech debt metaphor maximalism (Part 2)
Last time we explored analogies with financial instruments that don’t incur regular interest payments. Now let’s push the tech-debt analogy towards a clear, distributed view of who’s really borrowing
People might talk figuratively about owing a debt of gratitude or a debt to society, or how Velazquez and Rembrandt owed a debt to Caravaggio, but financial debt involves a transfer of funds between two counterparties. It establishes a relationship.
If you take out a mortgage this transfer of funds is well-documented. You assume a liability and the bank or building society – your counterparty – treats the loan as an asset on its balance sheet and makes a profit via the interest you pay on the outstanding mortgage amount.
Other borrowing might be less well-documented. Caravaggio fled Rome in 1606 after killing a man at a tennis match. Tennis can be aggravating, but the brawl was likely over gambling debt.
In both examples money has changed hands and someone eventually wants it back. So if a software development team takes on the liability that by analogy comes with technical debt, what is it borrowing, and who is the counterparty, whether documented or not?
The ‘what’ is easy enough to answer: it’s time, and as the saying goes, time is money. Financial models based on net present value and discounted future cash flow take into account the time value of money. No problems with the metaphor here.
The ‘who’ – the counterparty – is harder to pin down.
Borrowed time
The usual answer is that the team is borrowing from its future self because it will likely be required to pay back the debt through refactoring or rework. Ward Cunningham, who came up with the technical debt analogy, said later that “debt is localized within a team, its goals and the code offered by a team to meet those goals.”
This is true in practice – the team is most aware of the technical debt it took on and the impact it has – but the analogy with financial debt breaks down because there is no plausible counterparty. You can’t borrow money from your future self; that’s just called spending. Other developers – another company, even – might inherit the code base and the tech debt, but that’s a generational transfer, one team leaving a legacy for another, welcome or not.
None of these arrangements fits with the idea of one party holding an asset (lending money/time) and another party being responsible for the corresponding liability (borrowing money/time). The metaphor seems well and truly broken.
However, Cunningham’s later clarification of technical debt suggests an opportunity to fix it: “Any mechanism that attempts to measure team commitments, goals alignment and code quality across organisational boundaries would be valuable in our increasingly dependent world.”
Let’s extend the analogy across organisational boundaries, then, by treating technical debt as a kind of intercompany loan, a financial arrangement between related parties within the same organisation or corporate group.
A loan of this kind is typically intended to transfer funds and help manage cash flows, and is set up on an arm’s-length basis with comparable terms and conditions to an equivalent loan between two independent parties.
On this basis we could say that a product and engineering department receives a share of the organisation’s annual budget in the form of a loan that it will repay in kind, in the form of working, valuable software.
Product and engineering can make that funding go further in the near-term by taking on tech debt to speed up delivery and accomplish business goals faster. They will also uncover tech debt – possibly rooted in previous years’ development – when revisiting code to make improvements based on user feedback, or addressing changing business requirements and market conditions.
Take comfort
But software development teams don’t take on technical debt (including design debt) for their own benefit or to make life easier. In fact, they know that sooner or later it will make life harder for them and possibly for users as well.
Instead, software teams often find themselves taking on tech debt at the explicit or implicit request of other parts of the business: to make sure a new feature can have sufficient impact on sales during the current financial year; to land something in time for the conference where the marketing team generates lots of qualified leads; to quickly match something a competitor just did; or, yes, because someone important made a commitment to someone even more important.
So the intercompany loan comparison works up to a point, but doesn’t properly reflect business dynamics or the circumstances behind technical debt’s creation, which is what the metaphor was originally intended to do.
True, debt is localised within the team, but that doesn’t mean other parts of the organisation shouldn’t acknowledge the burden.
The appropriate analogy here might be with a “letter of comfort”, which in finance is a document providing an assurance of one party’s willingness to support another. Also called a letter of support, a comfort letter is non-binding, unlike a letter of credit or a letter of guarantee, both of which create a contractual obligation.
Tech debt may originate with software development teams, and those teams will have the best understanding of its nature and impact, but if the debt and the associated interest was taken on to deliver a product or feature faster, accelerating revenue growth or lead generation, that debt is a collective, corporate liability.
There are stories, probably apocryphal, of product managers handing out Monopoly money to stakeholders during strategy or prioritisation sessions to impress upon them that software development comes at a cost and the supply of money is finite.
When it comes to agreeing scope and deadlines, however, it would be better to ask sales and customer success managers, marketing and business development teams, to acknowledge trade-offs and recognise that the resulting technical debt is a business-wide responsibility. Ask for their support.
Recommended stuff
Tech debt metaphor maximalism by Avery Pennarun (the post that got me thinking about this article)
Introduction to the Technical Debt Concept by Jean-Louis Letouzey and Declan Whelan (including elaborations and clarifications from Ward Cunningham)
Technical Debt: an Incomplete Metaphor? by Rachel Stephens
Next time…
How to use concepts from financial accounting to structure and visualise technical debt