The other day I got into a small argument with coworkers during the Sailboat exercise about the meaning of “technical debt.” We were hunched over stickies and milling about thoughtfully. Suddenly I leaped from my chair and smacked a note on the whiteboard: application too big. The rent is too damn high!

This damn slice of monorepo in which we had been toiling over the course of the last sprint had blind-sided us as a super bloom of contributions from different teams. The code was getting hard reason about; we were hostage to the out-of-bounds-ness. It was getting too complicated:

It has many interconnected parts, each full of details. Conditionals abound, forming intricate rules that may surprise us when we read them.

Now, I was reticent to describe this anchor I threw on the boards as any kind of “debt” since I’d been thinking more about debt as the future IOW on quality to increase speed in the present. By that narrow definition, if this nuanced latticework were debt, we’d be able to rustle up the ledger and observe the amortization plan, hopefully incremental and steady. To think of complicated code emerging from a combination of variegated knowledge across teams, and the teleologic weight of entropy (bit rot, cruft, and so forth) didn’t situate in Cunningham’s metaphor for me because it showed up as a stunning surprise. Are we ever really surprised by our credit card bill?

There are other sources of debt people talk about that related negligence. Procrastination, not revisiting architecture, postponing test-writing. I truly believe the teams working in this code were doing it well, so that flavor wouldn’t help situation this present monorepo madness for me.

Well, there’s the whole category of “unintentional” debt. But that also felt wrong, too. There is an aspect of stuff out of our control but the intent/unintent dichotomy feels unsatisfying if software is a rich system of people, code, automations, feedbacks…I don’t know. Language is hard. I guess I’m gliding at the edges of a linguistic constraint with the lexicon that was tossed around the table by my colleagues. Some sort of weak Sapir–Whorfian confusion that I can’t peak around.

Nonetheless, I conceded to my fellow engineers of wares that are soft: ok, this debt that so cunningly creeped with bold surprise was, in fact, a (indefinite) form of technical debt. In fact again, the frame I particularly appreciated was this: while it may not have been a result of a conscious decision, now that we observed this mucky muck we could choose to deal with it as debt. Ok, debt is debt whether it arrives by forethought or entropy.

Luckily, as I was catching up on my daily doses of software newsletters this morning, jessitron (who I can’t stop quoting) hyperlinked her latest blog to another post from the Atomist site that gives us what I think is a more accurate language for this very type of technical debt. Frankly, any optimistic (re)casting of language in our field is welcome; we’re so prone to a feeling of unfinished, incomplete, or overwhelmed, everything is fine (eh, nope).

Technology drift is a form of technical debt that comes from progress. As our target architecture advances, it leaves a trail of projects in all its momentary incarnations. As repositories proliferate, the accumulation holds us back. We have many technologies and many versions of each. We have the risks of all of them.

TECHNICAL DRIFT

Fuck yeah, let’s use that!