The Common Notion of Technical Debt | ScaleTech Consulting

The Common Notion of Technical Debt | ScaleTech Consulting

The Common Notion of Technical Debt—Measuring and Reconciling Drag

Thanks to Ward Cunningham's metaphor of "technical debt," we now have a phenomenal descriptor for the resistance that software development teams face when reconciling their existing architecture after it falls out of alignment with the problem we're solving.

However, as a metaphor, it's just that. It explains and helps us visualize this resistance but doesn't provide us with a way to measure or account for when we "owe" too much.

Suppose we could somehow measure how much work was necessary and remains to bring yesterday's architecture in line with today's understanding of the problem. In that case, we could quantifiably measure our technical debt for any given project's sprint.

So, let’s do what Agile teams do, and find a way.

Introducing: Drag.

What is “Technical Debt”?

If you’re unfamiliar, the term “technical debt” stems from Agile software development. It was first coined by Ward Cunningham when he needed a way to frame why a non-technical stakeholder on a project should care about the hidden architectural attributes of a software system.

In order to quickly deliver the finished software product, his team had to begin with an incomplete understanding of the problem they were solving. Along the way, they would readjust both their understanding of the problem and the architecture of the solution they devised. However, if those became too misaligned, they’d have to revise the latter (i.e., by “refactoring”), or the solution would become increasingly difficult to build.

Teams can somewhat prolong this debt situation, but the more you put off refactoring your architecture, the further misaligned everything becomes. This eventually makes it hard to add new features or adjust to new understandings of the problem because your architecture is too different from what you’re trying to solve.

A given architecture’s inherent resistance to change is what Ward means by “debt” in his technical debt metaphor—and it’s a fundamental characteristic of all Agile methods.

(It’s a feature, not a bug.)

“Recipe Debt”?

Somewhat similar to Cunningham’s metaphor—suppose you order a cake from a bakery, one that you found on their menu that looks perfect. But you want it to taste like cheesecake instead of devil’s food.

(Maybe you’re just not into devil’s food?)

The baker needs to go back to square one to bake that cake. Maybe they try to use the devil’s food recipe anyway, but the more they reference it, the harder it will become to pull a cheesecake-in-disguise out of the oven.

Common Misunderstandings About Technical Debt

Unfortunately—and ironically—the way technical debt is sometimes used doesn’t always align with its true definition. Too often, people frame technical debt as resulting from poorly written code or too hastily constructed architecture.

It’s not either of those at all.

To start, it should be noted that software development in the 70s and 80s was slow. Enough so that delivered products ran the risk of becoming irrelevant or not accounting for the initial problem’s changes upon completion.

The Agile methodology’s emphasis on quick deployments addresses this issue. However, to be successful, it requires an incomplete understanding of the initial problem and architectural readjustments based on what you learn and the feedback gathered along the way.

Technical Debt is Not Poorly Written Code

Technical debt is about architecture and a natural occurrence of Agile methodologies, not poorly written code. If your code has high cyclomatic complexity, poorly named variables, magic numbers, and other basic errors, then it’s poorly written.

It’s simply bad code construction, not debt.

And having bad code is always avoidable because a skilled developer knows the rules of good code construction and puts them into practice on every project and sprint.

Technical Debt is Not Bad Architecture

The situation that technical debt describes is very specific: the problem and the solution's architecture are misaligned, and the development team will face increased resistance if they continue attempting to force them to work in harmony.

Your architecture might be flawless, and so too your current understanding of the problem. But there's a disconnect between them due to your attempts at solving previous understandings.

Perfectly designed architecture can be leaden down with debt if it doesn’t align with the problem it’s solving.

Technical Debt is Not a Static Property

If you owe $200, that amount likely has nothing to do with how you intend to use your money in the future. In contrast, technical debt only makes sense in the context of continually changing systems.

If your understanding of the problem remains fixed, then it’s not possible for technical debt to exist, let alone accrue. So we can’t look at a software system and quantify how much technical debt it has without trying to change it.

Trying to Measure Technical Debt and Make it Visible—From Story Points to Drag

As apt as Ward Cunningham's metaphor is, it doesn't help us during planning stages, daily scrum meetings, or when reporting to project stakeholders beyond explaining that the challenge exists, as there's no measurement associated with it.

We know it exists and must be accounted for—but we can't definitively say how much.

As a dynamic property, technical debt begins accruing when your understanding of the problem changes and you start realigning your architecture. Again, it describes the resistance you face when adapting a software system designed to do X into attempting a substantially different Y.

To measure that resistance, we can turn to a fundamental aspect of one Agile methodology: scrum’s story points.

Story Points

As a relative measure, "story points" estimate the required effort a team must dedicate to completing a "project backlog"—or an item on the list of features or changes required.

It's a projection of how difficult a specific task is, relative to other development efforts.

Crucially, story points are intentionally relative and not assigned any other valuations to keep teams operating in harmony. They remove potential politics or competitions of who can complete the most story points in the shortest time.

Despite their relativity, story points still apply here to technical debt.

If your architecture closely matches the new problems you want to solve, then you can add features or "pay" any existing technical debt with fewer story points. If there's a greater mismatch, it takes more. We could use a scalar story point measurement of how much technical debt exists in the system. However, this would require lots of risky estimation upfront, and it is out of line with agile principles of only estimating enough to accomplish the sprint goals.

Instead, the measurement should be vector-based, and I’ve started calling it “drag.”

Defining “Drag”

As a representation of how much your current architecture impedes the team’s forward progress, “Drag” quantifies technical debt.

It’s simply the ratio of story points that add value compared to those wasted on previous sprints’ architecture building efforts and tracked over time, sprint-by-sprint.

Estimating Drag

To estimate your team’s current drag—on a sprint-by-sprint basis—you need to know how to allocate story points to technical debt. It reveals itself through story points in ways that include:

  • Architectural adaptation bugs – Found in unplanned work, these include any unexpected behaviors arising from realigning the current system architecture to the problem you’re solving (e.g., object-relational impedance mismatch).
  • Unexpectedly high estimates for “easy” features – Found in planned work if project backlog items that seem simple start consistently being allotted more story points than you’d otherwise expect. Put simply, your current architecture is well-aligned and your team faces minimal technical debt if “it’s easy to do easy things.” More specifically:
  • Can you easily implement features that involve the same type of transformation as another you’ve already built? For example, if you have a feature that lets you make a button red, it should be simple and require minimal story points to add a feature that makes it or another button blue.
  • Can you easily represent different entities as belonging to the same category according to stakeholders' and users' minds? For example, if you have software that can represent cats as belonging to the category "animals," then it should be simple and require minimal story points to do so for dogs as well.

In a tangible sense, you can “see” technical debt accruing in planned work by how shocked your stakeholders are when you provide unexpectedly high estimates for a seemingly easy project sprint (and if you’d normally agree with them).

If these types of features should be completed easily (in theory) and with minimal story points, but they are causing major problems for your team, that’s a clear-cut sign of technical debt starting to weigh your team down

More Ways to Evaluate and Measure Drag

Sprint post-mortems are another opportunity to measure drag and evaluate current levels of technical debt. They’re a perfect time, as you can take an opportunity to reevaluate your architecture before risking that discovery mid-sprint.

Take a look at each feature or issue your team encountered and ask:

  • Was this bug due to architectural adaptation?
  • Was this story “too hard” to add?

If so—and your architecture was the culprit—mark those story points as contributing to technical debt.

Tracking a project’s drag this way will inform you whether it’s time to address technical debt by refactoring. If you see drag start to go up sprint-by-sprint, then you need to consider refactoring. If it’s holding steady or (better yet) declining, you might be able to wait.

Drag should also be used to inform stakeholders of current project impediments. In this way, you can communicate just how much technical debt there is to manage—which will help them make investment decisions and set expectations about the invisible architectural properties of our system.

Crucial Considerations and Caveats with Drag and Technical Debt

When applying the concept of drag to technical debt, keep in mind that:

  • Technical debt only occurs and makes sense regarding changing system contexts; significant roadmap changes negate any previous drag metrics and accrued debt.
  • Categorizing issues as technical debt is ultimately still subjective, so you shouldn’t treat it as a precise quantity. Instead, it should be thought of in the same way as story points, a subject measure of how “hard” something is, and used comparatively against previous sprints to see if drag grows or shrinks over time.
  • You shouldn’t play "what if" games, try to split story points, or think about how easy the issue would be under a hypothetical architecture to determine how many points were "wasted." Allocate the whole backlog item—you’re measuring your team's drag today—not what it would be under different circumstances.

If you’re struggling to measure your team’s technical debt and drag, or are seeking how to begin reducing it by reconciling your project's architecture, ScaleTech Consulting is ready to help.

Managing Technical Debt and Drag

Our consultancy services combine Agile development expertise and management skills that prioritize putting people first. We can also help you find the right team leaders or members through the People Gateway—our all-in-one staffing, recruitment, and staff augmentation solution that matches firms with top developer talent worldwide.

Contact us today to discuss your project or how we can help expand your team.


Ward Cunningham. Debt Metaphor.