Strategies for Tracking & Paying Off Technical Debt

Unless you are so fortunate to always be on a software development team that 'never cuts corners', more than likely you and your team have experienced the challenges of incurring 'technical debt.'

You all know what I'm talking about - your development team ultimately runs out of development time (or funding) in the late hours of a project and you end up making compromises to get code into production without necessarily wrapping your deliverable up the way you would like to in accordance with the best practices of software craftsmanship. Classic examples of technical debt include:

• Ninja Attacks - That late-break featuring that was 'Ninja Coded' in at 3 AM (you know who you are) to wow your customer, but there wasn't enough time to write tests.
• Not enough time to refactor - Instead of adding a new capability by refactoring the existing code base, taking the faster route to just copy and paste code from an existing capability and quickly modify it to satisfy those final requirements.
• Forgetting your code needs to run on someone else's box - Focusing only on delivery of the application code, while neglecting to maintain the required Configuration Management artifacts (such as install scripts, database schemas, documented library dependencies and technical standards, etc) that are required to successful deploy your solution to a target environment.

As noted at the onset, if you've never had to 'cut corners', give yourself a pat on the back. For the rest of us who in one way or another have wound up 'going into technical debt' the following strategies are aimed at providing a 'way forward' to track and close out technical debt items, ultimately improving the quality of your team's software product.

• Make your debt visible - As your team accepts compromises, make sure the entire team is aware of what's going on. Ideally, make a big poster, wiki page, or write and tag story cards that enable everyone to clearly see debt items; in an ideal world, all team members would be empowered to address debt items. Ensure that all members of the team can edit and augment the listing of debt items so no barriers exist to documenting new items that need to be addressed.
• Track debt items to resolution - Once a baseline of technical debt items has been captured (and is visible by all), ensure that as a team progress is made to address debt items. At a minimum keep track of a simple quantitative metric at a regular interval, such as total number of outstanding debt items each week. If for some reason your team finds it is necessary to add new technical debt items in the midst of efforts to close out debt items, that's a 'smell' that your team's capabilities and skills are not aligned with your software development process.
• Continually re-prioritize and group debt items to expedite resolution - At a regular interval (perhaps when you update your debt metrics), review your team's outstanding list of debt items. Prioritize debt items based on inputs from your team, your customer, and external stakeholders. Also be sure to look for debt items of a 'similar' nature; you may find you can increase your resolution velocity by focusing on debt items that stem from related root causes.
• Share your debt items with other software development teams - Sharing your debt items with other teams may enable collaborative solutions; perhaps another team in your organization is struggling with the same problem, and by working together you can ensure that a common mitigation is used across multiple teams, adding consistency and common patterns across your organization's code base.
• How about a round of 'debt war' with other teams? - By sharing debt items and metrics across teams, you may be able to invoke some 'friendly competition' amongst teams regarding who can address their listing of debt items faster. Perhaps your organization's leadership would support a cross-team competition to resolve debt items, awarding some type of prize for expedient closure of documented technical debt. Just imagine - you could address your team's debt items, perhaps win a prize (aside from the coveted bragging rights), and maybe even have a little bit of competitive fun with your colleagues.
• Don't be afraid to ask for help - Along the lines of sharing debt items with other teams, don't be afraid to communicate that your team needs assistance to resolve specific technical challenges. In the many instances technical debt items may arise from sources outside your team (such as a security audit or a third-party code review), you may find that those who documented the debt item have good ideas about how to mitigate the observed issue.

Most importantly, once your team's technical debt items have been resolved (or perhaps during the resolution process) don't neglect the importance of having a Project or Release Level Retrospective to discuss what precipitated the need to cut corners in your software development process and start incurring technical debt. Using the data from the Retrospective, add specific controls to your software development process to ensure that the 'costly' mistakes of incurring technical debt are avoided in the future.