In my last post I discussed the canonical definition of tech debt: the implied cost of additional work in the future resulting from choosing an expedient solution over a more robust one. In that post we met Software Engineer Sally who created some tech debt by choosing to implement a feature the Quick and Dirty Way instead of the Somehow Better Way.
Stu to the rescue?
Let’s imagine an alternative universe that is identical to that scenario in every way, except instead of Sally we have Software Engineer Stu. Unlike Sally, Stu is a new engineer, it’s his first month on his first job. Stu needs to implement the same feature as Sally, but Stu doesn’t know about the Somehow Better Way. Stu is new! We can’t expect him to know every design alternative under the sun.
When Stu fires up his IDE and consults a coding copilot tries his best to figure out a solution, the Quick and Dirty Way is the one he lands on, except Stu doesn’t see it as the Quick and Dirty Way. As far as Stu is concerned, it’s a Perfectly Good Way That Works Just Fine. It’s probably similar to the way the existing code already works.
Stu implements exactly the same feature as Sally in exactly the same way, except Stu isn’t choosing expediency over robustness. Stu just writes what he sees as a good working solution and calls it a day.
If tech debt requires a choice, then Stu has managed to avoid creating any tech debt at all. Nice work Stu.
This doesn’t seem quite right
The two systems managed by Sally and Stu are identical, but only Sally created some tech debt because Sally knew more than Stu did when she made her fateful choice. But if Sally’s system is going to require some rework in the future, surely Stu’s will too. This illustrates what I think is a serious weakness in the definition of tech debt – it depends too much on the psychological state of the people involved.
Engineers can and do disagree on architectural choices and their consequences so there will always be some element of subjectivity in a debate over expediency versus robustness. But insisting that tech debt is always and everywhere the result of a choice leaves us with the odd situation where tech debt surrounds one system but not another even though the systems themselves are the same.
You might claim that Stu did make a choice – he chose not to search for a better solution! OK, fine. How do you know when your search is done? How do you know you aren’t just one more hour of thinking away from finding the Obviously Better Way to do it? Still, you might say, Stu could have tried.
Seeing technical debt as the cumulative effect of a series of bad choices focuses the problem on a search for blame. Which, to be fair, is a pretty common way of framing the issue.
Tech debt as a boring corporate morality play
Conversations about tech debt often have a strong whiff of moral indignation where the shortsightedness of others has produced a tragic outcome. Like The Ant and the Grasshopper rewritten as a tedious corporate psychodrama with maximal technical pedantry.
The moral dimension of tech debt explains why choice is so central to the definition – you can’t be responsible for a choice you didn’t make. If tech debt just happens then where are we going to find our scapegoat?
Metaphors have consequences
By what is probably a highly non-random coincidence, debt also has more than a whiff of unsavoriness, which could explain the enduring popularity of tech debt as a concept. It might just feel good to see it that way.
Our Stu scenario makes the metaphor even shakier though. How do we fill the boxes:
Does anyone owe rework to anyone yet? Will they ever? If some tech debt arrives in a code forest, does it make a sound?
In future posts I will defend tech debt as a useful metaphor, while arguing the definition of tech debt needs major rethinking. In the meantime, here’s a very good boy who doesn’t owe anybody anything.
.