The Burden of Technical Debt

At its core, technical debt is a term used in software development that describes the implied cost of future re-work caused by choosing an easy solution now instead of using a better approach that would take longer. Many times, you can look at it as the difference between doing something fast versus doing something right (spoiler alert: sometimes doing something quickly is the right way). While we don’t deal with software development at General Public, we do see the impact of technical debt on many website builds and how a proper understanding of it can help avoid extra costs and headaches in the long run.

Types of Technical Debt

Not all technical debt is created equal, in fact, when used strategically technical debt can be a helpful tool in the right situations. Martin Fowler’s Technical Debt Quadrant is a great tool to visualize how technical debt can differ from situation-to-situation:

PRUDENT-DELIBERATE

If you’re going to take on technical debt, this is the neighborhood you want to be in. In this scenario, the decision to take on technical debt is well-informed with a clear understanding of what is being sacrificed for the sake of a final solution.

The absolute BEST kind of prudent-deliberate debt is the kind that has a plan in place for how to deal with the ongoing consequences or cost of the debt.

RECKLESS-DELIBERATE

Things start to get messy when the nature of deliberate debt changes from prudent to reckless. Reckless-deliberate decision making can take any number of forms, a few examples being:

• “We don’t have time for design.” – Spending time and money creating digital ads without giving thought to the post-click user experience or content strategy, resulting in low conversion rates, diluted brand equity, and inefficient budget allocation.
• “We don’t have time for testing.” – Installing widgets or plugins that cause code conflicts or user experience disruptions that distract from pre-defined goals.
• “We will pay a premium to keep the status quo, regardless of practicality.” – Trying to shoehorn functionality in a CMS that isn’t the proper platform for a site’s desired technical needs

When we look at reckless-deliberate decision making as it pertains to websites, we almost always see these decisions deliver disappointing returns. These debts risk impacting the overall effectiveness of the product or advertising effort (examples one and two) or end up costing more than an appropriate solution (example 3).

RECKLESS-INADVERTENT

If there was a quadrant where you needed to wave a red flag, this would be it. Reckless-Inadvertent debt is dangerous because many times it’s debt that is unrealized by members within a team while it is happening. Whether this debt occurs out of ignorance of best practices or poor team management, it needs to be avoided whenever possible.

PRUDENT-INADVERTENT

Is it possible to take on debt that’s both prudent and inadvertent? Absolutely. Martin Fowler describes realizing this type of debt in his article:

What you find is that the moment you realize what the design should have been, you also realize that you have an inadvertent debt.

I like to refer to this as “Shoulda-Woulda-Coulda” debt, and it happens to developers, designers, writers, and even project managers — sometimes there’s no replacement for the lessons learned in doing something the wrong way.

Taking it One Step Further

So how does this impact what we do? The biggest impact we see is when clients are deliberately prudent or deliberately reckless in the decision-making processes. For many small to midsize businesses, using a third-party service to incorporate advanced functionality on a website is the most accessible and cost-effective option available. We feel comfortable supporting technical debt when:

• We have reasonable expectations for what it will accomplish
• It will have a positive and measurable impact on the final product
• The client is comfortable with future ongoing costs associated with it

If utilizing a third-party tool checks off these boxes, we consider it a prudent-deliberate acquisition of technical debt. Prudent-deliberate debt also applies to design: we can ask all three questions to determine whether or not contributing resources towards custom design/development is “worth it.”