The methodology specialists at OnTechnicalDebt have the right emphasis: “technical debt” is a metaphor whose greatest power is to facilitate communication and analysis. Matt Holford, for instance, puts it concretely: “Not everyone understands test cases, aging platforms, crufty code bases, or security loopholes, but everyone understands debt …”

Realization of a metaphor

That quote is from Holford’s recent “Can Technical Debt Be Quantified? The Limits And Promise Of The Metaphor“, which also has the virtue of mapping limits of the metaphor. For Holford, “[f]inancial debt has but one form: Money owed”, while technical debt has at least a dozen dimensions he usefully lists. You’ll want to read his thoughtful, nuanced description for yourself; make sure you also scan the Comments for the reference to Don O’Neill’s earlier managerial perspective on technical debt and its impact on planning.

For me, the financial metaphor has a few more insights to supplement Holford’s description. Alexandra Szynkarski, likes Holford, aims to quantify technical debt. In her “Prioritizing Your Technical Debt“, she observes that individual items of financial debt have not only a principal–Holford’s “money owed”–but also an interest. One doesn’t strictly determine the other. Szynkarski implicitly recommends a return-on-investment (ROI) model for decision-making: “If there is an item that has a very high interest with a relatively low principal, then that’s the one you want to focus on fixing first.”

Similar advice is common from financial advisors: households with multiple debts should pay off loans with high interest rates first, while of course staying current with other items. That’s what I always practiced and preached in my personal life. In the software lab, that means “paying the minimum” to keep applications afloat, while simultaneously focusing on a single “high-interest” area of technical debt where the development team focuses all its surplus attention.

Smallest debt first

Dave Ramsey has a variation on that counsel that programmers need to consider. Ramsey is a mass-market financial counselor who targets people controlled by, rather than in control of, their personal finances. One element of his elaborate “Total Money Makeover” particularly deserves our attention in thinking about technical debt: Ramsey’s followers pay off their smallest debts first, rather than those with highest interest rates.

That sounds like an arithmetic mistake. On paper, Ramsey’s approach incontestably costs more than a highest-interest-rate-first plan. Ramsey himself, though, writes, “The math seems to lean more toward paying the highest interest debts first, but what I have learned is that personal finance is 20% head knowledge and 80% behavior. You need some quick wins in order to stay pumped enough to get out of debt completely. When you start knocking off the easier debts, you will start to see results and you will start to win in debt reduction.”

There’s a lot of wisdom in Ramsey’s approach, enough to extend to its application in the technical debt metaphor. As important as measurement is in software development, and as clear as the benefits of ROI planning are, I often attack technical debt with a heuristic that looks for early and easy wins. When struggling households are getting their finances under control, complex strategies are no benefit; they need a simple way to create sustainable behavior, stay current with their creditors, and simplify their balance sheet. Similarly, what’s most important for development teams under stress is not a complicated dependency diagram of subtly-prioritized programming tasks. Instead, programmers most need a simple plan that minimizes surprises, adequately copes with the daily surprises of stakeholder issues, and frees up a little time to focus first on a few easy problems. “Take out the trash” is one of the images I have for this early stage in cleaning up technical debt: pay off the lowest debts first, and thus clear away their distraction so that it becomes possible to target bigger problems more effectively, and with more clarity.

In analytic terms, think of the combinatorics of debugging: it’s much harder to solve four interacting errors simultaneously, than one or two in sequence. That difficulty is not only cognitive–it’s hard keeping all the variables clearly in mind–but attitudinal, in that it’s a psychological strain to keep moving forward with no clear “wins”.

Win now

Quantify what you can of your technical debt, and plan with your decision-makers in terms of rational priorities. At the same time, identify small, achievable goals, and start with successes you can achieve quickly.