What is Technical Debt –
Since agile developers believe in iterative development, they often choose to not predict what the best long term design will be. Rather they design just enough and just in time. This results in simpler and quicker to implement code. The goal is to produce functionality that meets the story acceptance criteria. If or when it appears a better or more robust design is useful, then this code will be refactored (changing the design without changing functionality) in the future.
This thinking is a mind-shift from traditional development that stresses, “build it once and never go back”. AKA: Big Up Front Design (BUFD). In fact, often changing existing code is risky because it was not built with change in mind. Often to change a single line, the developer may need to know how the whole code base works. This can be terrifying. Agile developers, especially using XP (Extreme Programming) Engineering practices, build for change. Refactoring requires first building a unit test bulkhead to isolate the area needing redesign.
Technical Debt is a term attributed to Ward Cunningham Ward explains the metaphor. Ward explains that this is a metaphor he used to explain why after releasing software it was worth going back to refactor.
Below is a model that Martin Fowler uses to describe how technical debt comes accumulates. This is known as the technical debt quadrant. His observation is that, in the process of development a team makes decisions either deliberately or inadvertently and these decisions can be either reckless or prudent.
An interesting aspect of this model is the recognition that there is inadvertent debt. Sometimes, as in the case of reckless/inadvertent there is not even recognition that there is a problem. Often in this situation, debt issues are only discovered after outside review or (sometimes repeated) production issues. In the best case, inadvertent debt is recognized retrospectively and the code is refactored to incorporate the learning.
Although many times technical debt does not have any immediate business impact, often (like untimely debt service) the impact is delayed. The impact can include poor performance, lack of flexibility or extendibility, poor reliability, or high cost to support.
How to Manage Technical Debt –
- Lessen The Impact
a. Build for change, small, modular, single purpose
b. Use TDD or otherwise very high levels of high quality unit tests - Identify/Track it
a. Record opportunities to improve code to fit normal design patterns 2. Code walkthroughs are a good way to identify areas to improve - Estimate it
a. Include this work when thinking about the estimate for a story that involves the area in the code needing improvement - Pay it
a. Refactor when a new story hits the area needing improvement
FAQ
Why not have separate technical debt stories?
The best way to refactor to pay technical debt is to do it in line when working on new stories. This keeps the team moving forward on the release goal. Just include the refactoring work in the story when it comes into a sprint. This maintains the team direction by the product owner.
We have a lot of debt. How can we pay this faster?
An alternative approach is to build a prioritized technical debt backlog. As the team can then work on these items by time boxing effort. For example, in a sprint decide to take a debt item and work no more than 8 hours. This keeps a steady payment pressure without mushrooming to take up all capacity.
The reason for the debt metaphor is that the points were borrowed or spent. You usually do not make money paying debt.
What’s the difference between a technical story and technical debt?
A technical story may or may not be technical debt. If it is an architectural feature that users would benefit from then it is just a story that the PO may not understand. If there is no agreement on the value, that story should not go into a sprint. The PO should set the priorities. It is best to incorporate technical debt refactoring in line with new product backlog stories.
Who decides when to refactor?
The team should feel empowered to identify what needs refactoring and when.
Is performance technical debt?
Performance requirements (when known) should be specified in acceptance criteria. The story should not be accepted if the acceptance criteria are not met.
More reading on how to manage your debt – More ideas about tech debt
Wicked Agile 