Last updated on July 9th, 2021 at 12:36 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.
Accepted classification frameworks are technologyoriented
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 technical debt literature 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 across technical activities.
An example might clarify the issue. Technologists tend to create classifications of technical debt that emphasize designer and implementor 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.
In the technical literature, this classification, and another due to McConnell [McConnell-slides 2013] are widely but not universally accepted. For example, some believe that no artifact is 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. The second reason relates to developing plans for retiring particular classes of technical debt. Knowledge of the intentions of the people who created (or omitted) the artifacts in question is helpful in planning debt retirement projects..
Policymakers need a more inclusive classification framework
For policymakers, while both of these widely accepted classifications are helpful, they are inadequate. Intentionality with respect to technical debt formation is indeed a valuable consideration in developing technical debt policy. But technical debt can arise for reasons unrelated to engineers’ intentions. Indeed, it can arise for reasons unrelated to any enterprise activity. For these reasons 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. They didn’t exploit capabilities that had become available. These sites were in need of updating to remain competitive in their markets. The new standard also created a ned to replace capabilities that emulated the new standard, but which exploited alternative technologies. 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.
Other posts in this thread
- Tension between policymakers and technologists
- Adopt an enterprise-wide definition of technical debt
- Exogenous technical debt
[Adobe Blogs 2014] Adobe Blogs. “What is Technical Debt?,” Adobe Blogs, September 8, 2014.
Available: here; Retrieved February 26, 2017.
[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
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
[McConnell-slides 2013] Steve McConnell. “Managing Technical Debt”, ICSE 2013.
Available: here; Retrieved November 11, 2017