The wall of technical debt: makes tech debt visual
Technical debt can be a major obstacle for organizations in achieving their goals. It is a term used in software development and can be described as the result of wrong decisions in the past, often due to prioritizing quick delivery over perfect code. Sometimes technical debt also arises because best practices from the past are outdated. Technical debt is not necessarily bad. Sometimes the rapid release of a new feature is more important than the maintainability of the code.
Maneuverability
You always pay the price of technical debt in time. When organizations spend insufficient time on getting rid of technical debt, the price can become so high that the further development of software will take an unreasonably long time. As a result, organizations become less agile. As a result, they are less able to react to changes in the market, putting them behind the competition. The big problem of technical debt is that it is often invisible. Developers can often indicate that the technical debt exists, but find it difficult to make a real cost/benefit analysis of it. The wall of technical debt is a tool that can help make this analysis.
The wall of technical debt is an idea of Mattias Verraes .
The purpose of the wall of technical debt is:
- Making technical debt visual
- Calculate a cost for each piece of technical debt
It’s a surprisingly simple concept where you use a board where everyone can stick sticky notes with things that have lost time. They don’t necessarily have to be things directly related to code. Everything that delayed you as a developer is valid: lack of documentation, incomplete tests or a strange bug that only occurs on February 31.
Dots on sticky notes
It is also important to note how much time has been lost. This is time that could have been spent implementing other software if this piece of technical debt had not landed on your path. Verraes emphasizes in his explanation that it is important for a team to agree on its own unit of measurement for time. For example, a single dot on the sticky note could represent half a day of lost time. In this way, every piece of technical debt becomes visual.
In addition to a description, it now also has a cost price. This cost price should be interesting for everyone within an organization that has an interest in rapid software development. Solving technical debt has a concrete return in the form of time. Teammates who lose time on the same issues can add their dots to existing sticky notes.
The main advantage of measuring lost time is that it makes technical debt objective. A piece of software can be built in the most horrible way, which makes further development difficult. But if it practically never needs to be changed, is it really technical debt? Such matters rightly do not receive attention on the wall, because they are not relevant.
The other half of the formula
However, by calculating the yields, we have only solved half of the formula. The other half concerns estimating the costs of resolving technical debt. By estimating the effort involved, it becomes possible to make a cost/benefit analysis. Estimating changes to software is never an exact science, so your estimate will not be completely correct. Yet it becomes evident that solving certain technical debt easily justifies an investment:
For the past four weeks, X and Y have been working on a new feature for their organization. In doing so, they ran into technical debt. After four weeks there are eight dots (each dot is half a day’s work) on the sticky note. During the development of the feature, four days of time was lost. X has estimated that resolving the technical debt will take approximately two days. X and Y present the situation to the product owner. They would like to know whether the roadmap still has a lot of work planned in the same domain as where the technical debt was found. The product owner indicates that this is the case.
A simple calculation tells them that the investment will pay for itself quickly:
- Expected work in domain: 12 weeks
- Expected time loss: 24 dots (12 days)
- Expected time investment solution: 2 days
The example above is an illustration of how technical debt becomes negotiable through the wall of technical debt. This makes it easy to value technical debt issues. In general, issues that have a high impact but require relatively little effort are the best candidates to solve (see impact/effort matrix). In this way, product owners or other stakeholders within an organization can become aware of the obstacles that developers have during the performance of their work. This is the responsibility of the developers themselves. As a professional, it is your responsibility to make the right choices for the organization you work for. Both in the short and long term.
Just before the lockdown in March, we decided to introduce a wall of technical debt. Even before we had actually set up a board, we suddenly all had to work from home. Initially we made a digital variant in a Google Sheet. However, the board then loses an important function: visibility. We are currently working on an improved digital variant that we can use until we can safely return to the office.