The other day I got into a tiff with coworkers during our retro sailboat exercise, hunched over stickies and milling about thoughtfully. Abruptly, I leaped from my chair and smacked a note on the whiteboard: application too big. Did this qualify as technical debt, and therefore start in motion various debt protocols and procedures (tagging, itemizing, scoping, slotting, mapping…).

The damned slice of monorepo which we had been toiling in since last sprint was damaging our pace with a super bloom of contributions from different teams. The code was getting hard to reason about, we were feeling immobile amidst the swarm; 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.

Lately I’d been thinking about debt as the future IOW on quality to increase speed in the present. A somewhat common definition. But that definition didn’t seem to characterize what I had slapped on the board. By that narrow definition, if this nuanced latticework were debt, we’d be able to rustle up the ledger, analyze the running amortization plan, protocls and procedures and so far and get eh work scheduled or assigned as noop or what-have-you. Yet, but nope, 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) – that didn’t situate in Cunningham’s metaphor for me. All this new code was showing up as a stunning kind of surprise not as a calculated tradeoff.

Perhaps other sources of debt people discuss could help us understand our current morass? Could it be situated as procrastination, not revisiting architecture, postponing test-writing? I don’t think so. I truly believe the teams working in this code were doing right by all these additions.

Then there’s the category of “unintentional” debt. But that still missed. There was an aspect of stuff out of our control but the intent/unintent dichotomy felt unsatisfying if do, in fact, believe that 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 couldn’t peak around.

Nonetheless, I conceded to my fellow engineers – to wares that are soft:

ok, fine, 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!