Last updated on June 3rd, 2018 at 04:09 pm
Technical debt needn’t result from anyone’s conscious decision. In some instances, technical debt seems to appear as if by spontaneous generation. And that creates problems for technical debt management programs that assume that technical debt results from employee decisions in the form of the intentions of engineers or others.
Although knowing author or engineer intention relative to technical debt artifacts can be helpful when organizations plan or execute technical debt retirement programs, sound technical debt management policy must address situations in which author or engineer intention wasn’t a contributing factor in creating the debt, or intention can’t be determined, or intention is concealed. Classifications of technical debt must therefore consider business strategy and resource availability as well as author intention.
This difference in priorities contributes to tension between technologists and policymakers with respect to their definitions of technical debt.
Within enterprises of significant size, classifying technical debt is an essential step in designing programs for reducing the cost of carrying technical debt. Although the choice of classification scheme depends on one’s objectives, most classification schemes explored so far in the literature of technical debt are more suitable for use by technologists than by policymakers. But, unsurprisingly, the assistance they provide to policymakers relates mostly to policies that affect technologist behavior or resource allocation within the space of technical activities.
An example may clarify the issue. Technologists tend to create classifications of technical debt that emphasize author intentions. For example, Fowler has created a widely accepted two-dimensional [Lowy 2004] classification [Fowler 2009] that characterizes technical debt according to the Degree of Wisdom in incurring it (he calls this dimension Reckless/Prudent), and Degree of Intentionality in incurring it (he calls this dimension Deliberate/Inadvertent). See “Technical debt in software engineering” for more.
This classification, and another due to McConnell [McConnell-slides 2013] are widely accepted in the technical literature—widely, but not universally. For example, some believe that no artifact can be deemed technical debt unless its presence (or absence) was the result of a conscious decision [Adobe Blogs 2014]. Some adherents of this view would reject all of Fowler’s “Inadvertent” technical debt.
This focus on engineering intention likely arises, in part, for two reasons. First, technologists tend to have good access to their own intentions, and to the intentions of other technologists. Second, knowledge of the intentions of the people who created (or omitted) the artifacts in question can be helpful to technologists as they develop plans for retiring particular classes of technical debt.
For policymakers, both of these widely accepted classifications, while helpful, are inadequate. Intentionality with respect to technical debt formation is indeed a valuable consideration in developing technical debt policy, but because technical debt can arise for reasons unrelated to engineers’ intentions—indeed, it can arise for reasons unrelated to any enterprise activity—intention-based classifications provide inadequate guidance for policy formation.
Consider technological advancement that arises from sources external to the enterprise. For example, with the emergence of the HTML5 standard, many Web sites became obsolete, in the sense that they didn’t exploit capabilities that had become available. These sites were in need of updating to remain competitive in their markets. And capabilities that emulated the new standard, but which exploited alternative technologies, needed to be replaced. All of these artifacts—including those that existed, and those that didn’t, comprise technical debt.
Relative to technical debt management, an enterprise that devotes resources to monitoring external technology trends would have an advantage over competitors that tend to focus solely on employee behavior.
Technological advancement that occurs outside the enterprise can thus create technical debt within the enterprise. This is just one example of spontaneous generation of technical debt. Thinking about technical debt this way, you can probably identify other sources of spontaneous generation. Together, they create a need for policies that can address their management.
Available: here; Retrieved February 26, 2017.
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
Available: here; Retrieved November 11, 2017