Tag: technical debt quadrant

Posted on

Spontaneous generation

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.

U.S. Army soldiers, along with volunteers from the community, install roof trusses for a Habitat for Humanity home in Brainerd, Minn., July 13, 2010
U.S. Army soldiers, along with volunteers from the community, install roof trusses for a Habitat for Humanity home in Brainerd, Minnesota, July 13, 2010. Hurricane ties are in place at the top of the wall as the roof trusses are being placed. The Florida state building code was strengthened in 2002 to require hurricane ties to strengthen the connection between the roofs and walls of buildings. Homes built before 2002, and which lack hurricane ties, are therefore carrying technical debt. Retiring that debt is difficult. It involves retrofitting hurricane ties which usually requires cutting holes in the home’s siding—one for each tie—and then repairing the holes. Photo by Sgt. Nicholas Olson, courtesy  Wikimedia Commons, where you can find a larger version of this image.
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 technology­oriented

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.

Last words

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

References

[Adobe Blogs 2014] Adobe Blogs. “What is Technical Debt?,” Adobe Blogs, September 8, 2014.

Available: here; Retrieved February 26, 2017.

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[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.

Order from Amazon

Cited in:

[McConnell-slides 2013] Steve McConnell. “Managing Technical Debt”, ICSE 2013.

Available: here; Retrieved November 11, 2017

Cited in:
Posted on

Technical debt in software engineering

Ward Cunningham, who coined the technical debt metaphor

Last updated on July 7th, 2021 at 10:47 am

Ward Cunningham, who coined the technical debt metaphor
Ward Cunningham, who coined the technical debt metaphor. Photo (cc) Carrigg Photography.

Ward Cunningham coined the technical debt metaphor in the context of developing a software asset [Cunningham 1992] [Cunningham 2011]. He observed that when the development process leads to new learning, re-executing the development project—or parts of the project—could lead to a better result. For this reason, among others, newly developed operational software assets can contain or depend upon artifacts he regarded as technical debt. In hindsight, the developers recognize they could remove these artifacts altogether. Or they could replace them with more elegant, effective, or appropriate forms. In this way, they could enhance maintainability, defensibility, and extensibility. To deploy the asset in pre-hindsight condition would entail an obligation to return to it in the future to implement the improvements. That obligation is Cunningham’s conception of the asset’s technical debt.

Fowler’s technical debt quadrant
Fowler’s technical debt quadrant. Intentionality is the vertical axis; Wisdom is horizontal.

In the decades since Cunningham coined the term, the meaning of technical debt has evolved. It now includes much more than Cunningham’s original concept. Martin Fowler developed a 2×2 matrix (which I interpret as Intentionality x Wisdom) that describes four different pathways that lead to technical debt creation. Cunningham’s concept corresponds to what Martin Fowler describes as, “now we know how we should have done it” [Fowler 2009].

At a conference in Dagstuhl, Germany (“Managing Technical Debt in Software Engineering”) in 2016, leading experts in software technical debt research developed a verbal definition of technical debt for software-intensive systems [Avgeriou 2016]:

In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.

With the definition of technical debt enlarged in this way, software engineers can focus on instances of software technical debt that reduce enterprise productivity and agility. But is this definition sufficient as a foundation for enterprise policy? I explore that question in “A policymaker’s definition of technical debt.”

References

[Adobe Blogs 2014] Adobe Blogs. “What is Technical Debt?,” Adobe Blogs, September 8, 2014.

Available: here; Retrieved February 26, 2017.

Cited in:

[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.

Available: here; Retrieved: March 10, 2017.

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Cunningham 2011] Ward Cunningham. “Ward Explains Debt Metaphor” (video; here; ).

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[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.

Order from Amazon

Cited in:

[McConnell-slides 2013] Steve McConnell. “Managing Technical Debt”, ICSE 2013.

Available: here; Retrieved November 11, 2017

Cited in:
Posted on

What is policy?

Last updated on July 8th, 2021 at 11:46 am

DuBrin defines policies as “… general guidelines to follow when making decisions and taking action” [DuBrin 2016]. Some policies are written, some are unwritten. Some have names or identifiers, some don’t. For organizations seeking to gain control of technical debt, written policies are probably a good idea, for two reasons:

  • Many people affected by technical debt policies are probably unfamiliar with the technical debt concept. A written policy is more likely to be communicated uniformly to everyone.
  • The effort spent devising a written policy is likely to surface ambiguities, confusions, and differing needs. That’s one of the benefits of devising written policies. Resolving these issues during the policy formation process is better for the organization than resolving them during the deployment process.

A useful policy is clear. It uses terminology that’s simple and well-defined.

Properties of technical debt policy

Achieving these goals for technical debt policy formulation can present special problems. Much of the audience for the policy is unaware or incredulous of the connection between their own behavior and technical debt formation.

Specifically:

  • The policy must address an issue—technical debt—that has mainly technological manifestations
  • The policy must provide guidance for people as they make choices
  • Some of the choices that people make will produce technological manifestations
  • The connections between the choices and the technological manifestations can be obscure, especially
    when the choices don’t appear to be technical
  • Some technical debt arises from phenomena unrelated to behavior of anyone within the organization

Said differently, technical debt policy must confront four issues:

  • Some people whose behavior we must modify are unaware of the consequences of their behavior
  • Some of those same people strongly believe that the technical debt problem results from malpractice by others
  • Current incentive structures play an important role in technical debt formation
  • Some technical debt arises from phenomena external to the organization

Effective technical debt policy must therefore include these elements:

  • An education component to help people see the connection between their choices and technical debt formation
  • A situational awareness component to alert the organization to internal and external developments that could cause technical debt formation
  • A means of allocating resources to technical debt management that holds accountable the business units whose actions contributed to technical debt formation
  • A means of committing future resources to technical debt retirement

References

[Adobe Blogs 2014] Adobe Blogs. “What is Technical Debt?,” Adobe Blogs, September 8, 2014.

Available: here; Retrieved February 26, 2017.

Cited in:

[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.

Available: here; Retrieved: March 10, 2017.

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Cunningham 2011] Ward Cunningham. “Ward Explains Debt Metaphor” (video; here; ).

Cited in:

[DuBrin 2016] Andrew J. DuBrin. Essentials of Management, Tenth Edition. Indianapolis, Indiana: Wessex Press, 2016.

Order from Amazon

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[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.

Order from Amazon

Cited in:

[McConnell-slides 2013] Steve McConnell. “Managing Technical Debt”, ICSE 2013.

Available: here; Retrieved November 11, 2017

Cited in:

Related posts

  • Who are the policymakers?
    As I use the term in this blog, a policymaker is someone who is responsible for developing, revising, or approving organizational policies that affect technical debt management.
  • A policymaker’s definition of technical debt
    The policymaker's definition of technical debt is neutral relative to its causes and manifestations. Its focus is what technical debt costs if we leave it in place, what advantages it offers, and what we would need to do if we decide to retire it.
Show Buttons
Hide Buttons