Eliminate technical debt, we can help!

“If you carry this way of working on for months or years, you get a lot of technical debt …” says the article analysed in our series on agile methodologies. A major shortcoming of the paper is that it only states, but does not justify; it is not open to debate. So, instead of debating, we will tell you what can cause this situation and how to prevent it according to our experience.

Sacrificing quality on the altar of speed is the root cause of technical debt. Here we have to point out that these reasons do not only arise in agile environments. There are many manifestations of this, some examples:

• Critical errors must be corrected quickly. In such cases, hacking is a perfectly sound strategy: if a sharp system failure is costing the company, say, a million dollars an hour, no one cares or should care about the elegance of the solution; speed is key. The problem is that once the failure is fixed, other tasks become urgent and the clean-up is delayed.

• A similar case is when critical improvements need to be made quickly. In this case too, the development team is reoriented when the new feature is already working, and the clean-up is again delayed.

• It may also be the case that a new need arises for code that perfectly meets the previous requirements, which would require a code restructuring to improve it. If we do not assume that part of the cost of developing the new requirement is to redesign the existing system as necessary, again there will not be time to do a good quality job.

• It can happen, especially when the team starts working with a new technology that early solutions turn out to be not timeless. As they become more familiar with the new technology, they discover what could have been done better. Of course, you don’t need to rewrite the entire code base for every idea that comes up, but if you never make these changes, you will certainly be piling up debt.

However you get to technical debt, it always creates tension between the business and development sides. The business is frustrated and doesn’t understand why development keeps slowing down; development is also frustrated because the business doesn’t allow time to refactor and the pressure keeps building.

One of the principles of the Agile Manifesto is: “Continuous attention to technical excellence and good design enhances agility.” This is perhaps too permissive of a formulation; it could also be said that without a focus on technical excellence, it is not possible to work sustainably and in an agile manner.

It is therefore necessary to make refactoring part of the daily work, and if this is not enough, a larger scale refactoring is needed and should be given space in the development process.

It’s a common phenomenon that developers, if they could, would constantly tweak the code, and the business would always rush ahead. In between, a balance has to be found between these two extremes. We suggest two ways to do this:

• The development side should be able to “sell” technical debt reduction tasks to business.
What works best for us in such a case is not to look at why it is important to carry out the refactoring in question, but what the consequences will be if it is not done. E.g.: “the current solution can serve up to 25 competing users”, “files larger than 3 MByte slow down processing, it can take several minutes”, “no automatic test can be added to the code, so you have to manually test this module before each release”, …
Thinking “what do we lose if we don’t do it” helps to translate the technical task of refactoring into business language, and also helps to filter out the changes we want to make just to satisfy our personal sense of beauty.

• Once the right communication has been established between the business and the team about the technical debt, in many cases an agreement is reached that the team can devote x% of capacity to such tasks. This saves the Product Owner from having to prioritise backlog items they may not understand and takes the decision to the right level: where the knowledge and information is available. At the same time, because the team has a finite budget, it also helps to avoid technical tasks that don’t provide real value: the team will regret the time spent on them.

Based on the above, it is our personal view that in a well-functioning agile environment, the problem of technical debt is an acknowledged and consciously managed issue, and is much more likely to be actually “paid off” than in a traditional environment.