Can Technical Debt be a force for good?
Technical Debt is always a hot topic. It is discussed mostly in the context of poor organisational culture forcing an increasing burden on developers.
But is this the only way to view Technical Debt? Have we moved away from the original concept in failing to acknowledge that it can be a positive force?
Technical Debt - a refresher
Technical Debt is a powerful concept, first described by that name by Ward Cunningham back in 1992.? The idea of technical debt seems to have really caught on, although people's interpretation seems to vary.
The success of the concept is because it is readily understood and easily communicated.? It can be use even with a non-technical audience, because we believe we all broadly understand about financial debt.? By phrasing development issues in a shared, non-technical language, we can more easily gain understanding and "buy-in" from the wider organisation.
Shipping first time code is like going into debt. - Ward Cunningham 1992
So what do we mean by "Technical Debt"? As argued by Cunningham, as soon as you deliver your first code, you have associated commitments around that code. Shipped code is never "free", but there will always be some on-going cost to maintain and support the code.
Those commitments can be considered a "debt". As with a financial debt, the more debt you have, the more repayments you have to make. Ongoing maintenance acts like "interest" on the debt. Paying "interest" in this case means doing work related to the past deliverables. And this work removes effort from creating new value, so slowing future development.
The effect of Technical Debt, as with financial debt, depends considerably on how much debt we have to pay. If we have delivered a large amount of poor quality code and now must maintain it, our "debt" is high. We will need to commit more time to supporting the product. This will reduce the speed at which we can deliver new value to customers.
Potentially we could reach a crisis point where the code is so complex, fragile or poorly written that all of our effort is needed to maintain the code we have deployed to date and future development becomes impossible.
Simplicity – the art of maximizing the amount of work not done – is essential - Principles of the Agile Manifesto
Read: Importance of common language https://agileplays.co.uk/a-common-language-and-processes/
Read: What is technical debt https://agileplays.co.uk/understanding-and-managing-technical-debt/
Understanding Technical Debt
When I talk to developers about technical debt, they mainly highlight errors and bad practice. This is the general view of technical debt and is also how it is perceived outside Engineering departments. Technical Debt is often viewed as a tax to pay for developer errors, and this compounds the reluctance of organisations to invest in improvement work. To developers refactoring is inevitable, but to external stakeholders it can be unclear why the team didn't "get it right the first time".
Martin Fowler introduced a model for Technical Debt which really helps us understand the different types of debt that we might see. He grouped technical debt in two dimensions. In one axis he considers whether the debt is incurred deliberately or inadvertently. In the other dimension, whether it is prudent or reckless.
Deliberate technical debt, in this model, is when we have made a conscious decision to take on the debt. We understand that we are taking on technical debt and we decide to go ahead and do so. It may sound unusual, but as we will see it is not uncommon.
By contrast, inadvertent technical debt is where we adopt technical debt without really realising it. We take actions which, because of our lack of knowledge, increase technical debt. To most people this is the type of adoption which they are considering when they discuss technical debt.
Read: Complex environments https://agileplays.co.uk/what-is-complexity-and-why-is-it-a-problem/
Bad technical debt
Bad technical debt adoption is not distinguished by whether the debt is deliberate or inadvertent. It is determined by the other dimension. Bad technical debt is reckless, in that we have no plan to deal with the consequences of the debt.
This is the case which is most often discussed when we are considering technical debt. We might inadvertently introduce reckless debt. This could occur when the team is out of its depth with a new technology. It forges ahead creating a product, releases it and moves on. Most likely the product is poorly structured, over-complicated and non-optimal. That's no-one's fault, because the team could initially not do better. But there is no plan to deal with the consequences.
Deliberately introducing reckless debt seems more unusual. It could be a conscious decision to abandon design and rush into coding. Perhaps this decision is to hit a tight schedule, despite clear warnings from an experienced team about the potential consequences. This is something that seems to occur not infrequently. It is linked to the organisational culture and directive management and a lack of listening to engineering teams is often at the heart. The issues with the Space Shuttle Challenger are an example of the consequences of failing to address known issues.
Read: Groupthink risk https://agileplays.co.uk/groupthink-risk-for-high-performing-teams/
Read: Psychological safety: https://agileplays.co.uk/what-do-we-mean-by-psychological-safety/
Good technical debt
However, it is interesting to see that Cunningham originally saw Technical Debt as a positive force.
It is often forgotten that Cunningham worked at the time in a finance organisation. When he invented the concept of Technical Debt it was to communicate with people in that industry who viewed debt as a far more positive factor.
From a financial viewpoint, debt is an enabler which allows you to access more capability than you could unaided. You could not, for example, easily purchase a house without access to debt.
Cunningham explains the concept below.
I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience. - Ward Cunningham
As we see Techical Debt was originally not about overall product quality and instead about the balance of quality and learning. We see a similar concept in Eric Ries' work on the Lean Startup, where he emphasises the importance of focus on learning.
Any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time. - Eric Ries, The Lean Startup
Good technical debt, or in Fowler's model "prudent" debt, can be considered technical debt which allows us to learn. The end product is better as a result because we use the learning.
It could still be inadvertent. We might not know the answers for a new technology area and so be focussing on learning. The results therefore will be imperfect but we will have learned how to do this correctly.
Or it could be deliberate. We may need to deliver to gain market feedback from which, again, we learn and improve.
Whichever is the case, we learn, we use that learning to go back and address the technical debt and make something better than we could initially have made.
The key point in prudent use of technical debt is the existence of a feedback loop.
Good Practices
As an Agile Leader you should ensure the organization considers how to address Technical Debt prudently. This means two key points:
Learning is continuous, and so technical debt reduction and refactoring is also continuous.
I help scaling tech organisations with systems and structures to achieve repeatable delivery.
If you want to discuss how I can help your organisation, drop me a message.