Technical debt is one of the primary impediments to long-term software product success. Every team feels the pressure to deliver value frequently to the business. At the same time, we know that we need to keep our code clean and supported by tests to operate at a sustainable pace. Regular technical debt sprints are one way to make our “interest payments.”
When time is short, even a well-disciplined team may cut a few corners. They might implement a code solution or automated tests in a less-than-optimal design, or make changes in old production or test code without taking time to refactor it. Future changes to this production or test code will be harder and take longer.
Ward Cunningham coined the term “technical debt” to represent the unfinished work due to shortcuts taken by the team to deliver a feature or user story faster. If we “borrowed” by skipping important steps, we have to pay back that “interest” quickly. If not, the interest will keep mounting up, and the growing technical debt burden will slow us down or even immobilize us.
Technical Debt Sprints
One way to pay down our technical debt is by devoting an entire iteration to activities such as refactoring production and test code to make it more maintainable and understandable, learning new ways of working better, upgrading test and code framework and tool versions, and improving the “living documentation” (also known as “automated tests”). We skip delivering new business value for just that iteration so we can pay down our technical debt.
“Sounds good,” you say, “but our product owner is never going to let us spend a whole iteration and not deliver new user stories to the business.” Or, you might be thinking, “Aren’t we supposed to ruthlessly refactor all the time? Why spend a whole sprint on refactoring?”
Even a highly disciplined team may run into limits to continual refactoring. If we have a lot of legacy code that is not supported with automated tests, it’s time-consuming to refactor and too risky if we don’t simultaneously add the tests. We also need to refactor our test code to keep tests maintainable and efficient. But, it can be risky to change our tests while code is changing.
There are other considerations. The team should choose its strategy. The work done in one quarter or a six-month period is going to be the same whether the team’s technical debt keeps growing—forcing them to work more slowly—or they devote some time exclusively to reducing the technical debt. Even with continuous refactoring, we find it works better to take some time to understand the debt and take the right steps to manage it for the long term. (See the sidebar for a helpful game about technical debt.)
Article continues below.
|
Technical Debt: Hard Choices Nanda recently came across a game that explains technical debt and the results of not paying it back. The game, called Hard Choices , was designed by the Software Engineering Institute (SEI) and adapted from Shortcut: A Game About Speed and Risk by Elisabeth Hendrickson. Basically, the game has the aspects of taking shortcuts (creating debt by incurring penalties) and paying it back (by losing a turn). If you don’t pay your debt, it will take you longer to reach the end. Players can move in any direction and can even change directions in a single turn. They earn points by racking up “tool” cards and by being the first one to get to the end. For each bridge they cross, they must subtract one from subsequent rolls of the die. Nanda plays differently than |
About the author
Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.
About the author
Nanda Lankalapalli is an architect, Certified Scrum Practitioner, and agile coach. He built and led high-performance teams and is an active contributor to the agile community. Nanda is one of the founders of the Agile Hyderabad user group and has spoken at several agile conferences organized in Hyderabad, India. Nanda is part of Eplan Services and telecommutes from India.
