Technical debt

“If you carry this way of working on for months or years, you get a lot of technical debt …” states the blogpost we have been covering recently. Unfortunately, it is only a declaration, lacking any kind of explanation. Therefore it is impossible to argue with. Instead, we will talk about what we have seen as the causes of this situation and what can be done to avoid it.

The root cause of technical debt is sacrificing quality for speed or quantity. Please note that this cause is not restricted to an agile environment. A few examples of how this problem can surface:

– A critical error needs to be corrected quickly. In this case a quick-and-dirty fix can be a valid strategy: if the company is losing money by the million dollars each hour due to a critical failure of the live system, the elegance of the solution is not a priority, and it should not be. In this case, speed is of utmost importance. The problem is that after solving the problem, implementing the proper solution and cleaning up is often forgotten due to other emergent urgent tasks.

– A similar case is when a critical piece of development has to be completed in a short amount of time. Afterwards, the development team is set to a new direction as soon as the new functionality is working. Cleaning up is omitted again.

-Sometimes a new requirement arises that necessitates restructuring a piece of code that was completely suitable for all previous requirements. If we don’t take the cost of restructuring the system into consideration, there will not be enough time allocated to put the appropriate amount of work into development.

-If the team starts to work with new technology, the first solutions might not be long-lasting. As the team is getting familiar with the know-how, they discover better solutions. Of course it is not necessary to rewrite the whole codebase with each new idea; but if we never perform the necessary modifications, we will certainly accumulate a significant amount of technical debt.

Regardless of how technical debt is acquired, it will always build tension between business and development. The business side will be frustrated and will not understand why development is permanently slowing down. Development will also be frustrated because of the constant pressure and lack of refactoring time.

One of the principles of the agile manifesto states that “Continuous attention to technical excellence and good design enhances agility.” This might be a very permissive phrasing, we could as well say that continuous attention to technical excellence is a requirement for agility and for maintaining a constant, sustainable development pace.

Therefore it is essential that refactoring is performed as part of the daily work and if this does not suffice, and major refactoring is needed, it has to be taken into account during development.

It is a common phenomenon, that developers always want to beautify the code, business people always want to rush forward with feature development. Find the right balance. There are two ways to do this:

-Development must “sell” the tasks aiming to reduce technical debt to business.
What has worked for us is that in such cases we do not try to explain the reasons why refactoring is needed. Instead, we explain the cost of not doing it. For example: “With the current solution we are only able to process a maximum of 25 concurrent user requests”, “processing files over 3 MBytes is extremely slow, in the minute domain”, “we cannot auto test the code, we have to test the module by hand before each release”.
Thinking about “what we will lose if we don’t do it” helps in translating the technical task of refactoring to terms business understands. It also helps in filtering out those modifications which are only for our very own aesthetic reasons.

-If there is already proper communication between business and the team about technical debt, it is common to reach an agreement that a certain percentage of team capacity can be used for these tasks. This solution saves the Product Owner from prioritizing backlog items (s)he might not fully understand and shifts the decision to the proper level, where information and know-how is available. At the same time – as this budget is limited – we can opt out tasks which provide no real value: the team will not waste time on these.

If we take all the above factors into consideration, our opinion is that in a healthy agile environment the problem of technical debt is a recognized and managed issue. Thus the chance of “repaying” this debt is much higher than in a traditional environment.