Last updated on July 8th, 2021 at 01:20 pm
Many an enterprise culture includes, perhaps tacitly, an unrealistic definition of done for projects. Some enterprise cultures assume definitions of done that fail to adequately acknowledge attributes related to sustainability. For such cultures, technical debt expands inexorably. In most organizations, the definition of done includes meeting the attributes that most internal customers understand and care about. These attributes might not include sustainability [Guo 2011]. Indeed, even among technologists, the definition of done might not enjoy precise consensus [Wake 2002].
Why retiring technical debt isn’t included in “done”Internal customers understand less well the attributes of deliverables related to sustainability. It’s therefore perhaps unsurprising that sustainability might not receive the attention it needs. Applying scarce resources to enhance attributes the customer doesn’t understand, and cares about less, will always be difficult.
To gain control of technical debt, we must redefine done to include addressing sustainability of deliverables. Although there may be many ways to accomplish this, none will be easy. Resolution will necessarily involve educating internal customers to understand enough about sustainability to enable them to justify paying for it.
The typical definition of done for most projects ensures only that the deliverables meet the requirements. Because requirements usually omit reference to retiring newly incurred nonstrategic technical debt, we often declare projects complete with incremental technical debt still in place. A similar problem prevails with respect to legacy technical debt.
A more insidious form of this problem is intentional shifting of the definition of done. This can happen when the organization has adopted a reasonable definition of done that allows for addressing sustainability. But under severe time pressure, the definition is “temporarily” amended to allow the team to declare the effort complete, even though sustainability issues remain unaddressed.
For most projects, three conditions conspire to create steadily increasing levels of nonstrategic technical debt. First, for most tasks, the definition of done is that the deliverables meet the project objectives, or at least, they meet them well enough. Second, typical project objectives don’t restrict levels of newly incurred nonstrategic technical debt, nor do they demand retirement of incidentally discovered legacy technical debt. Third, budget authority usually terminates upon acceptance of delivery. These three conditions, taken together, restrain engineering teams from immediately retiring any debt they incur. Nor can they retire—or document or report—any legacy technical debt they encounter while fulfilling other requirements.
For example, for one kind of incremental technical debt—what Fowler calls [Fowler 2009] Inadvertent/Prudent (“Now we know how we should have done it”)—the realization that we’ve incurred new debt often occurs after the task is “done.” If budget authority has terminated, there are no resources available—financial or human—to retire that form of technical debt.
Unless team members document the technical debt they create or encounter, there is risk of lost knowledge. After team members move on to their next assignments the enterprise is likely to lose track of the location and nature of that debt. A more realistic definition of done would enable the team to continue working post-delivery to retire or document any newly incurred nonstrategic technical debt. They could also note any incidentally encountered legacy technical debt. Moreover, teams most likely leave in place any strategic technical debt—technical debt incurred intentionally for strategic reasons. Although the enterprise must eventually address such debt as well, the widespread definition of done doesn’t address it.
Policymakers are well positioned to advocate for the culture transformation needed to redefine done.
[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.
Available here; Retrieved January 10, 2016.
- Technical debt in software engineering
- Team composition volatility
- How performance management systems can contribute to technical debt
- Unrealistic definition of done
- Spontaneous generation
- Legacy debt incurred intentionally
- Controlling incremental technical debt
- Refactoring for policymakers
[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.
[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.
Other posts in this thread
- Nontechnical precursors of nonstrategic technical debt
- Failure to communicate long-term business strategy
- Failure to communicate the technical debt concept
- Technological communication risk
- Team composition volatility
- The Dunning-Kruger effect can lead to technical debt
- Self-sustaining technical knowledge deficits during contract negotiations
- Performance management systems and technical debt
- Zero tolerance and work-to-rule create adversarial cultures
- Stovepiping can lead to technical debt
- Separating responsibility for maintenance and acquisition
- The fundamental attribution error
- Feature bias: unbalanced concern for capability vs. sustainability
- Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma
- Confirmation bias and technical debt
- How outsourcing leads to increasing technical debt
- How budget depletion leads to technical debt
- Contract restrictions can lead to technical debt
- Organizational psychopathy: career advancement by surfing the debt tsunami
- The Tragedy of the Commons is a distraction
- The Broken Windows theory of technical debt is broken
- Malfeasance can lead to new technical debt