Technical debt is a reality that any programmer or programming team needs to face, but it is a reality that comes in many forms. Each team within an organization may see technical debt differently from another, and even individual developers have their point of view when it comes to what technical debt is.
I will not try to give you a definitive definition of technical debt, but I think of it this way...
Technical debt is essentially making trade-offs within an application’s overall quality; and that quality has many different elements, from performance to security to stability to even how well-written it is. Often those trade-offs create issues that will need to be dealt with in the future. Developers almost always have a timeline to get a feature done, and they meet that deadline as best as they can while producing the most stable, resilient, well-written, and secure code possible.
The domino effect
The developer or development team must address all these different elements or attributes of a feature, but often that feature has more requirements than meets the eye. For example, putting a banner onto a website may require several changes. It may require security changes, process changes, or integration with a third-party service.
Because a development team will almost always be working to a deadline, the team will try to complete the feature within a sprint, and it will estimate that it will take however many sprints to complete it. But whilst working on this feature, the team may discover they need to spend more time on making it stable or making sure there is minimal performance overhead. Often the team may need to spend time patching security holes that have just been opened up by the change.
Whenever this happens, the team asks the question, “Is this a high enough level problem that we should stop the feature from going to production? Or is this such a low priority issue that we either a) address it as technical debt later, or b) highlight it and put it in the backlog for later?”. Because these trade-offs are constantly happening in any software company, technical debt essentially grows and grows and grows and eventually becomes a much bigger problem.
How to address technical debt
One approach to avoiding technical debt building up to the point where it is a problem is to interleave product sprints with a Hardening Innovation and Planning (HIP) sprint. A common scenario is that a team will do three product sprints of two weeks each and then work on an HIP sprint for one week. The HIP sprint allows the team to catch up on some of those technical debt items that have not been addressed in sprints.
It works really well in all areas because, generally, in the production sprints, the team wants to be fast, active, to be releasing, and pushing the boundaries; it is that high velocity of movement within the teams that gets everyone pumped to effectively achieve the team’s goals.
The HIP sprints work well because it provides relief between the three two-week production sprints. It is not a week to slack off, but it is a week to address some issues, particularly urgent ones, and think about how some other issues should be addressed. Because if they are not addressed in the HIP sprint, they will probably never get addressed. Unfortunately, addressing technical debt often gives the company little short-term benefits other than improving the underlying code. A company is not going to see any significant changes to the application, and it is not going to make more money directly out of reducing technical debt 99 percent of the time. However, the long-term benefits and savings are worth it in terms of making the technical stack more stable, secure, and easier to maintain.
Getting management on board with HIP sprints
Although HIP sprints are highly effective, it can be difficult to get organizations to agree to them because to take out one week out of every seven is a huge expense for the company. It has to pay one week’s wages and have one week of no product changes and releases and so forth. A company is not going to make dollars directly from an HIP sprint, but indirectly, it is going to see improvements in security, so its products are less likely to be vulnerable and attacked. If a team’s focus is to improve performance, it is going to be releasing faster, and there are going to be fewer delays, so that saves time. So, indirectly, there are a lot of benefits, but it can be difficult to quantify and, therefore, to sell to management.
The 5 to 10 percent approach
There’s another approach that is less radical and, as a result, less difficult to sell to management. That is to allocate five to 10 percent of each sprint to addressing technical debt. Unfortunately, the tendency is that everything else in the sprint is addressed first and technical debt is left last or not done at all because there has been an issue which leads to more technical debt and so on. So team leaders really need to be disciplined and ensure that the technical debt items are prioritized - if it’s important enough, such as a huge security vulnerability opened by the most recent piece of work, it should be addressed before any further work is performed.
At the very least, part of the team should work on resolving the issues in parallel. That approach can work, but unfortunately, technical debt often continues to grow in that scenario because it is the lowest priority within a sprint, and the can keeps getting kicked down the road.
All things considered
Whatever the approach, organizations that address technical debt in a structured way end up with higher quality applications that are more secure, more stable, more resilient, and perform better. Development teams are happier because they feel they are producing a quality product and customers are happier because better quality applications are going into production.