Technical Debt - Part I

Are you drowning in Tech Debt? Maybe your product partners are in feature factory mode and don’t want to pay down tech debt? Or maybe you have agreement on the priority and engineering capacity to draw down tech debt that then evaporates when you actually plan sprints? Are you tired of sounding the alarm bell that tech debt has reached an overwhelming level, but no one listens until there is an outage for customers – that of course you are blamed for.

Why is it A LOT harder to actually make progress on cleaning up tech debt than it should be?

Welcome to a video from AKF Partners on this topic, which is part of a short series of videos to help you keep your Tech Debt under control and generally keep your application house in order!

Part I in this series focuses on the importance of defining Tech Debt, the definition itself and a commentary about the value of Tech Debt – that is – is it good or bad?

Many of our clients struggle with managing Tech Debt for a multitude of reasons. As this series progresses, we will present practical strategies for mitigating the factors that may result in Tech Debt getting to an overwhelming level.

So what is Tech Debt? Seems obvious doesn’t it? But without a common documented definition of the term, we see many teams where stakeholders are not defining Tech Debt in the same way. And it follows that if stakeholders are not talking about the same defined bucket of work, then it becomes nearly impossible to have an aligned strategy to prioritize and manage Tech Debt on an ongoing basis.

Let's start with a brief history of the term.

The Tech Debt metaphor was first coined by Ward Cunningham circa 1992. Metaphors are useful tools to help bridge knowledge gaps by associating a new or complex concept with a more commonly familiar concept.

Ward’s original words relating Tech Debt to the idea of Financial Debt, were something to the effect of

“Shipping first-time code is like going into debt. A little debts speeds development....the danger occurs when the debt is not repaid.”

Tech debt started out as a good metaphor to Financial Debt, but has become a relatively broad catch-all term for any engineering work that is not focused on building new features. The unintentional expansion of the definition of tech debt in most organizations has made it more difficult for stakeholders managing this work, primarily Product Management and Engineering, to align on the level of effort needed to effectively manage it. In addition to Product Management, key strategic and financial stakeholders such as CEOs., CFOs and heads of businesses also understand the financial metaphor.

But when the definition of Tech Debt is expanded and/or ambiguous the Financial metaphor breaks down and is therefore meaningless and not helpful in creating a common definition for stakeholders to align to.

So let’s define Tech Debt in a precise way and take this metaphor back to its financial roots.

AKF defines Tech Debt as -

An act of commission that requires acting with forethought. Since forethought is required we only assume tech debt knowingly. In short, Tech Debt is the debt we take on when we decide to do something fast but in a suboptimal way, in order to get to market faster.

This definition is consistent with the metaphor to Financial Debt. We take on financial debt knowingly. The idea of financial debt that is assumed without the debtors knowledge does not exist. Or if it does exist it would be defined as fraud – that is – you can’t go into financial debt without making the decision to do so.

Therefore, acts of omission where engineering forgets to plan or do something, and mistakes like bugs - do NOT count as tech debt.

For an ongoing business, Tech Debt should refer to a part of the code that was initially implemented in a suboptimal way and should be fixed or improved in the future.

There are some cases where addressing the tech debt in the future may not be necessary. For example, if Tech Debt is acquired testing product market fit and you find parts of the product do not fit after testing with users, those portion may be deprecated rather than improved to meet standards, but in most cases for a going concern business, you will want to go back and improve the part of the code that has debt .

But is Tech Debt good or bad? Well, if we are properly using the definition, then we need to first answer the question - is financial debt good or bad?

Like many things in life – some debt for a business is usually appropriate in moderation.

When a corporation assumes debt, it is able to use the debt to fund investments in the business. For example, debt could be used to fund a new or fast-growing product build out.

In addition to cash flow generated from ongoing operations, companies can choose to raise funds by selling an equity stake in the firm or by issuing debt. Selling an equity stake by issuing new shares dilutes ownership, while debt does not dilute ownership. Debt does however result in future interest payments.

The runaway problem with debt comes if the amount of interest becomes overwhelming to the point the debt can no longer be serviced.

In the case of a software system, the interest payments are the extra time needed to work within the code in the areas where the debt exists. The principal payments are akin to actually going into the code and moving the initial implementation from suboptimal to optimal or meeting your architectural and coding standards.

As we have discussed, conflating the Tech Debt definition with other types of non-feature related application health work, essentially renders the financial metaphor and definition meaningless and can lead to mistrust between Product and Engineering - as other mistakes or acts of omission are lumped in with the conscious decision to take on Tech Debt. Our partners in business may think we are hiding the truth if we do not clearly delineate the difference between tech debt – and mistakes, failures, or other issues related to maintenance.

Following are some examples of other work that are commonly thrown in the Tech Debt bucket but are not tech debt:

• Poor architectural choices that later need to be re-implemented
• Managing the backlog of production bugs
• Addressing improvements identified in Incident Post Mortems
• Creating unit tests
• Addressing emerging security threats
• Performing upgrades on parts of the system

But the items above are things that we need to think about when building software and we ALSO need to dedicate capacity to. So if they are not Tech Debt then what are they?

Common terminology for these non-tech debt items include:

• Keep the lights on
• Maintenance
• Sustaining work
• Or Run the Business

In the next video we will discuss best practices for managing all of this application health work on an ongoing basis but today you can get started by creating a documented definition for Tech Debt within your organization that is consistent with the Financial metaphor and you will be off to a great start!