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. (commadot.com)

Oh, the Comic Sans. So whimsical. (commadot.com)

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.

The Human Cost of Tech Debt

Editorial Note: I originally wrote this post for the Infragistics blog. Head over to their site and check out the original. While you're there, have a look at the other blog authors and their product offering. If you're not already familiar with the concept of technical debt, it's worth becoming familiar with it.

 

 

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?

By Davey Ahearn

Thanks to Joe McCormick and Esteban Amas