Technical Debt (for Semi-Technical People)

Spend enough time (any) in product management and you’ll become a close acquaintance of “technical debt”: code inefficiencies, duplication, general bloat, temporary-ish shortcuts… the remediation of which will wreak havoc on your backlogs.

It’s as sure a development truism as any: with every line of code comes along some amount of future refactoring. In fact, I’ve found the only “clean” sprint is a company’s very first. After that, all bets are off.

Already?!

In recent years tech debt has become more accepted: boards, CEOs, and exec teams increasingly (albeit grudgingly) expect to see it in long-term roadmaps. Despite this there remains a pervasive misunderstanding of what technical debt actually is. The common takes:

• It’s a one-time problem. “Let’s just get it over with.” (I got a “Why the hell haven’t we fixed all this tech debt already?” verbatim from the CEO once, regarding a decade-and-a-half-old platform’s… decade-and-a-half’s worth of debt.)
• It’s an indulgence for the neckbeards in engineering — unnecessary for the product, but required to appease software perfectionists.

Nah. Tech debt is rarely an aberration, and addressing it isn’t a perk for devs. It’s just a consequence of any software product at scale.

A Google Doc Metaphor

Consider a Google Doc.

A Google Doc allows multiple people to edit altogether and over time. It’s a collaborative paper. C’mon, you know what a Google Doc is.

Assume you’re writing a story in a new Google Doc. You have a map of characters and a plot outline, and dive right in. So far so good.

Now, add people to “help” you write this story. Say, ten. Let’s have these ten contributors write alongside you, in the same doc, for 4–6 hours a day.

Imagine what will happen to your finely-structured narrative in a few minutes, not to mention days and weeks. What will befall your characters? How will you maintain a consistent theme or story as you and ten other writers — each with your own styles, opinions, and abilities — add new chapters and subplots, and try to edit others’ to match?

Now push this concept out from ten, to 50, to hundreds of writers, and for years. What will your story possibly read like after five years of daily, continuous addition and revision by hundreds of people?

It will be unbearably long. It will be messy. It will be inconsistent. (At best!) More likely it will be an incoherent cacophany. And while it’s possible to institute processes and systems to help manage such scale, inevitably the thrust of work across so many contributors will outpace your efforts.

(Consider, too, making a significant change to your story after so much time. A character’s name is easy enough— find and replace, just like changing a CSS class — but what about adjusting her underlying characteristics or motivation, or whatever resembles a character arc? How would you even find all the places to update?¹ This, more than anything, is where technical debt rears its head: it impedes the agility of change.)

And this, my B.A.-degreed friends, is sort of like technical debt: a giant Google Doc mangled by hundreds of well-meaning, individually capable people, over years.²

Pretty gross. So what can a semi-technical person do about it?

1. Mostly: understand. Recognizing the scope and permanence of technical debt will help you in every conversation about addressing it.
2. Acknowledge that relentless pursuit of “the new” will inevitably add debt. Be considerate of the long-term consequences of your decisions, and accordingly restrained.
3. Be as attentive to your debt as makes sense. Accommodate refactoring regularly if you can. (If pressures of the business prevent this, make the decision to accrue debt knowingly, and make it transparent.)
4. From the outset, allow architectural input. If your roadmap is sufficiently known, let engineers plan for at least the medium term. Don’t aim to avoid technical debt, but don’t strive to be so agile as to never look beyond the next two weeks. Be prudent where you can avoid introducing it.

Finally, be kind to your developers. In an old enough codebase, their day-to-day story might really suck.

[1] I once sat with a developer working on SMS notifications, in which a code search brought up more than 1500 “twilio” mentions across hundreds of locations. “That’s an easy map of where to change our SMS handling,” I thought, until I realized that not every developer would have used “twilio” in naming functions or classes. Moreover, this is a best case scenario! Few services or components will rely on such a searchable brand name as Twilio.

[2] This also helps to see why, to developers, a “replatforming” holds such appeal — or why a one-day feature takes a maddening four sprints, and why estimates are such a challenge.