Technical Debt — In Plain English

In business, all human problems are also business problems, viewed with a wide enough lens. Unhappy humans are unhappy workers, and unhappy workers are less productive. — Eric Dietrich

This summer we ramped up our prototyping efforts to implement some of our collaborative content creation concepts into a minimal viable product that we can test and use. As our “summer of sprints” nears its end, we realize that “technical debt” has been a reoccurring theme in our lab the whole summer. We found ourselves constantly making decisions about whether we implement a feature in the quick way, and “fix it later” (incurring technical debt), or implement the feature in a better way or more scalable way, but ship less capability.

Oh, the Comic Sans. So whimsical. (

While businesses tend to address quality/speed trade-offs with some sort of policy or approval process, this issue of technical debt has been much stickier for us, because it’s more like an ethos. This ethos is applied by individual people; software engineers making decisions based on this ethos can breakdown into the smallest level of granularity (atoms, electrons, quarks… the analogies are infinite.) It also doesn’t seem fit for guidance by an overarching policy, due to how different each macro- and micro-case is from its peers.

If you are one of those people who think, “I’ve got a great idea, I’ll just hire some developers and build it!”, take a look at the following blog post. It’s a great explanation of what technical debt is, and frankly, why building software is hard.

Software pros: How do you communicate your technical debt tolerances to your teams, and do you have a way to bubble up reporting of this incurred debt from low levels of code implementation into some foundational metric or conversational rubric?