Abstract/Description
Technical debt is a burden on software innovation that we would rather avoid, and certainly clean up whenever possible. However, in most organizations, people don’t prevent technical debt nearly as much as they should, and they rarely get the time to clean it up.
Why, then, if there are clear incentives to deal with technical debt, is it a rampant problem?
This session focuses on how to deal with technical debt on several levels, including the individual developer, the team, the software value stream, and the larger organization.
While technical debt may manifest itself in a developer’s IDE, the problem starts long before the developer decides to copy and paste some code, or creates an overly-complex and under-documented class. The pressures on teams and individuals to take on more debt than they should come from many sources so the solutions to the technical debt problem must extend beyond the team.
As a result, this presentation takes an eclectic approach. Some of the highlights include the following:
- An overview of technical debt. This section draws on various concepts from software economics to explain why a little bit isn’t necessarily bad, but more than a little can be awful.
- The triumph of short-term thinking. The Technical Debt Initiative created the Dice Of Debt game to demonstrate the importance of making long-term investments in reducing debt. This game is always a highly effective starting point for discussion of the reasons why people get stuck in the short-term thinking that increases debt.
- The steps required to deal with technical debt, and the costs of both remediation and non-remediation. This section draws heavily on the work of the Technical Debt Initiative.
- The distorting effect of technical debt on the team and the value stream. Cynefin and other theories of complexity are major elements in this part of the discussion. You may recognize the dysfunctions of your organization in this section.
The discussions of these topics include strategies that have worked for teams fighting technical debt.
For example, how can you use a simulation like Dice Of Debt, or the software economics of technical debt, to make a case to executives and middle managers that the investment in reducing debt is worth making?