Category: Nonstrategic technical debt

Posted on

Team composition volatility

Last updated on July 7th, 2021 at 07:51 pm

Now we know what we should have done.
“Now we know what we should have done.” This is one kind of incremental technical debt. When the composition of a development team changes over the course of a project, recognizing how the team should have been done things can become more difficult.

Team composition volatility can interfere with technical debt retirement. In many organizations, project team composition evolves from the beginning of the project to its end. In most teams, people who have special knowledge cycle in and out as the work requires. These changes in team composition might not interfere with completing a team’s primary objectives.

But these changes can affect the team’s ability to retire technical debt incurred over the life of the project. Changes in team composition can also limit the team’s ability to retire specified legacy technical debt that it encounters while working toward its primary objectives.

The likelihood of incurring nonstrategic incremental technical debt can also increase when team composition changes. Changes can also reduce the likelihood of retiring all legacy debt specified in the team’s objectives.

Why team composition volatility matters for incremental technical debt

Groups we call teams are responsible for carrying out most product development, maintenance, and enhancement. In this context, team usually refers to, “a small group of interdependent individuals who share responsibility for outcomes.” [Hollenbeck 2012] However, as Hollenbeck, et al., observe, teams vary widely in both skill differentiation and composition stability. My sense is that both factors can potentially influence a team’s ability to retire incremental technical debt. They also affect its ability to achieve its objectives with respect to retiring legacy technical debt.

For example, consider what Fowler calls the Inadvertent/Prudent class of technical debt—“Now we know how we should have done it.” [Fowler 2009] In a project of significant size, some might recognize that different approaches to all or parts of the project would have been better choices. The recognition might come several months or years after completion of the work.

But for the moment, consider only cases in which the recognition occurs during the project, or shortly after completion. In these cases, the people who performed that work might have moved on to other teams. The people who now realize “how we should have done it” might themselves be incapable of making the needed changes, even if they have the budget or time to do the work. Or worse, they might not have the knowledge needed to recognize that a different approach would have been more effective. In either case, recognized or not, the work in question comprises incremental technical debt. Because of team composition volatility, recognizing or retiring that incremental technical debt can be difficult.

Why team composition volatility matters for retiring legacy technical debt

Team composition volatility can also interfere with retiring legacy technical debt. Some projects have specific goals of retiring a class or classes of legacy technical debt. But others with different objectives might also be charged with retiring instances of legacy technical debt as they encounter them. When we reassign team members who have special knowledge required for the team’s primary objectives, some legacy technical debt can remain extant, if retiring that debt requires their special knowledge. It can also remain extant if the reassignment occurs before they can complete the legacy debt retirement. This mechanism is more likely to occur when the legacy debt retirement objective seems subordinate to other business objectives.

Last words

Keeping team membership stable has big advantages relative the technical debt management. Said differently, organizations that must shuffle people from team to team as a consequence of controlling costs by reducing headcount can pay big penalties in terms of increasing loads of technical debt.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[Hollenbeck 2012] John R. Hollenbeck, Bianca Beersma, and Maartje E. Schouten. “Beyond Team Types and Taxonomies: A Dimensional Scaling Conceptualization for Team Description,” Academy of Management Review, 37:1, 82–106, 2012. doi:10.5465/amr.2010.0181

Available: here; Retrieved: July 8, 2017

Cited in:

Other posts in this thread

Posted on

Technological communication risk

Last updated on July 7th, 2021 at 07:50 pm

See no evil, hear no evil, speak no evil
Hear no evil, see no evil, speak no evil—the iconic representation of communication failure. Technical debt can result from communication failures due to unwillingness to inform others of what you know, and unwillingness to receive information from others more knowledgeable.

Technologists must convey what they know about long-term technology trends to enterprise strategists and others. In addition to strategists, the interested parties include internal customers of technology, product owners, product managers, project sponsors, and senior management. Within the enterprise, technologists tend to be among those most knowledgeable regarding the relative alignment between enterprise technological assets and long-term technology trends. Yet technologists frequently fail to communicate this knowledge effectively to those who need it, and that can lead to nonstrategic technical debt. I call this phenomenon technological communication risk.

Technological communication risk is the risk that knowledgeable people within the enterprise don’t communicate important knowledge about technology. Within the enterprise are people who need this information and people who possess it. The risk is that people who possess it might be barred from distributing it, and people who need it might be unwilling to receive it. Policymakers can address this problem by working to define roles to clarify communication responsibilities. Role definitions must specify the need for this communication, and the need to be receptive to it.

A clear understanding of long-term technology trends is important in managing technical debt. Any significant misalignment between enterprise technological assets and long-term technology trends creates a risk of incurring new technical debt. As technologies evolve, enterprise assets must evolve with them. The gap between those assets and the state of the art is a source of lost productivity and depressed organizational agility, which is our definition of technical debt.

The root causes of technological communication risk

Some technologists are better informed about technology trends than are their internal customers, product owners, product managers, project sponsors, or senior management. Technologists often do attempt to communicate what they know on an informal basis, but unless such communication is expected and defined as an official duty, their superiors and internal customers don’t always welcome the information, especially if they haven’t heard it elsewhere, or if it conflicts with what they’ve learned elsewhere, or if its implications conflict with established strategic positions.

Many technologists are aware that their superiors might not welcome their observations about technological trends. And they are also aware that their superiors do not welcome observations about technology-based strategic vulnerabilities or opportunities. For example, a technologist might be reluctant to mention a cybersecurity risk that would be expensive to mitigate. This mechanism is especially strong when deploying adequate cyberdefense would compete for resources with other initiatives already underway. The mechanism is also important when the negative consequences of the vulnerability are unlikely to materialize. And some tend to question technologists’ credibility when they blame the technologists for the vulnerability itself.

Situations like these can lead to the formation of new nonstrategic technical debt in circumstances such as when Management directs technologists to…

  • …produce capabilities using approaches known to the technologists to be technological dead ends.
  • …implement capabilities that don’t exploit known approaches that could open new and vital lines of business.
  • …focus resources on initiatives that in the view of the technologists lack sufficient technological imperative.

Last words

Policymakers can mitigate technological communication risk by establishing internal standards that encourage knowledgeable technologists to share what they know. The parties that most benefit from the information are internal customers, project sponsors, or senior management. Similarly, those standards can encourage people in such roles to take heed when knowledgeable technologists do speak up.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[Hollenbeck 2012] John R. Hollenbeck, Bianca Beersma, and Maartje E. Schouten. “Beyond Team Types and Taxonomies: A Dimensional Scaling Conceptualization for Team Description,” Academy of Management Review, 37:1, 82–106, 2012. doi:10.5465/amr.2010.0181

Available: here; Retrieved: July 8, 2017

Cited in:

Other posts in this thread

Posted on

Failure to communicate the technical debt concept

Last updated on July 7th, 2021 at 07:48 pm

A tensegrity 3-prism
A tensegrity three-prism. Read about tensegrity structures. Image (cc) Bob Burkhardt courtesy Wikimedia.

The behavior of internal customers and users of enterprise technological assets can contribute to technical debt formation and persistence. Because of these contributions, introducing effective technical debt management practices requires widespread behavioral changes on the part of those internal customers and users. Accepting these changes, and the initiative and creativity they require, is possible only if people understand the technical debt concept. When they do, they can appreciate the benefits of controlling technical debt, and the consequences of failing to control it. Similarly, when they do not understand or accept the technical debt concept, progress toward effective technical debt management is unlikely. Policymakers can contribute to the planning and execution of the required organizational transformation.

Even when engineering teams are aware of the technical debt concept, and when they do try to manage technical debt, progress can be elusive. Significant progress requires the support and understanding of engineering management, internal customers, and customers’ managements. Everyone must understand that controlling technical debt—and retiring it—is a necessary engineering activity that has a business purpose. Everyone must understand that technical debt arises as a result of everyone’s behavior—not just the behavior of technologists.

Part of the job of Management is to ensure that engineers have what they need to avoid incurring technical debt unnecessarily. Management must also ensure that they have what they need to retire elements of legacy technical debt on a regular basis. Internal customers must understand that communicating their long-term business strategies to Engineering is essential for limiting unnecessary creation of artifacts that become nonstrategic technical debt. Only by understanding the technical debt concept can internal customers learn to avoid the behaviors that lead to nonstrategic technical debt, and adopt behaviors that limit new technical debt.

The tensegrity structure metaphor for technical debt management

Tensegrity structures provide a metaphor for organizations that have mastered the technical debt concept. Tensegrity structures use isolated rigid components in compression, held by a network of strings or cables in tension. The rigid components are usually struts or masts, and they aren’t in contact with each other.

The struts correspond to the users or customers of technological assets. The cables correspond to the engineering activities required to support the customers. The organization is stable relative to technical debt only when the two kinds of elements (struts and cables) work together, each playing its own role, but each appreciating the role of the other.

Advocating for cultural transformation

Advocates of any change to organizational culture are often seen as acting in their own self-interest. That’s a common risk associated with cultural transformation. It’s a risk that can lead to failure when inserting practices related to technical debt management into the culture. The risk is greatest when advocates for change are drawn exclusively from the technical elements of the enterprise. The ideal advocates for these ideas and practices are the internal customers of the technical organizations, and senior management.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[Hollenbeck 2012] John R. Hollenbeck, Bianca Beersma, and Maartje E. Schouten. “Beyond Team Types and Taxonomies: A Dimensional Scaling Conceptualization for Team Description,” Academy of Management Review, 37:1, 82–106, 2012. doi:10.5465/amr.2010.0181

Available: here; Retrieved: July 8, 2017

Cited in:

Other posts in this thread

Posted on

Failure to communicate long-term business strategy

Last updated on July 8th, 2021 at 01:11 pm

Failure to communicate long-term business strategy can lead to increased technical debt. This happens because engineering decisions that aren’t aligned with business strategy can result in what later becomes technical debt. As business strategy veers away from the assumptions underlying those misaligned engineering decisions, engineers must alter implementations to track the strategy. Technical debt can form during those alteration efforts.

Moreover, the resources that support those alteration efforts might have been unnecessary if senior managers had kept technologists better informed about long-term business strategy. In some cases, the result would have been a reallocation of those resources to other pursuits, including technical debt retirement. To ensure alignment of engineering decisions with long-term business strategy, engineering decision makers must be aware of long-term and intermediate-term enterprise strategy. When they are aware, they can anticipate the engineering needs of the enterprise. And they’re more likely to make decisions that are compatible with strategy.

Strategists can benefit from keeping technologists informed

A plug-in electric vehicle being recharged
Recharging a  plug-in electric vehicle. The dominance of petroleum-powered vehicles is nearing its end. Further investment in the petroleum-based fuels infrastructure is now  inconsistent with what the global economy has chosen as its strategic intent. Electric vehicles are still out of the reach of most consumers, but they would be wise to favor long range vehicles. As electric vehicles become ascendant, petroleum filling stations will become more widely spaced. The wider spacing reduces the metaphorical interest charges on the technical debt of yet-to-be-retired petroleum powered vehicles. During the transition to electric power dominance, a long-range petroleum-powered vehicle offers clear advantages over its shorter-range cousins.
The effect is bi-directional. Strategists can benefit from understanding the effect their strategies have on technological activity. For example, consider the process of choosing among strategic options. A favorable outcome is more likely if strategists know the effects of each option on the technical debt portfolio.

To gain effective control of technical debt, senior management must regard the technical elements of the enterprise as strategic partners [Woodard 2013] [Ross 2000] [Brenner 2016a]. Policymakers can make important contributions to enhancing communication between strategists and technologists.

For example, when engineers know the general direction of the enterprise, they can focus efforts on assets that are compatible with future needs. Inversely, when they’re unaware of the business strategy, they’re more likely to make decisions that they must later rescind.

What about legacy technical debt retirement?

Analogous considerations apply to legacy technical debt  retirement efforts. Major technical debt retirement efforts are often subject to review for alignment with enterprise strategy. But we tend not to review incidental retirement efforts that occur in the context of routine maintenance or development. Consequently, engineers might allocate effort to incidental debt retirement unnecessarily if the asset is due for overhaul or replacement. Communicating long-term strategy effectively is likely the most reliable way to prevent such misspent effort.

Last words

Some managers elect to communicate business strategy to technologists only when they “need to know.” Often, technologists needed to know long before that.

References

[Brenner 2016a] Richard Brenner. “The Psychology and Politics of Technical Debt: How We Incur Technical Debt and Why Retiring It Is So Difficult,” Cutter Business Technology Journal, 29:3, 2016, 21-27.

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Hollenbeck 2012] John R. Hollenbeck, Bianca Beersma, and Maartje E. Schouten. “Beyond Team Types and Taxonomies: A Dimensional Scaling Conceptualization for Team Description,” Academy of Management Review, 37:1, 82–106, 2012. doi:10.5465/amr.2010.0181

Available: here; Retrieved: July 8, 2017

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

[Woodard 2013] C. Jason Woodard, Narayan Ramasubbu, F. Ted Tschang, and V. Sambamurthy. “Design Capital and Design Moves: the Logic of Digital Business Strategy,” MIS Quarterly 37:2, 537-564, 2013.

Cited in:

Other posts in this thread

Posted on

Nontechnical precursors of nonstrategic technical debt

Last updated on July 8th, 2021 at 01:09 pm

Nonstrategic technical debt is technical debt that appears in the asset without strategic purpose. We tend to introduce nonstrategic technical debt by accident, or as the result of urgency, or from changes in standards, laws, or regulations—almost any source other than asset-related engineering purposes. In this thread I examine a variety of precursors of nonstrategic technical debt that aren’t directly related to technology. Sources of these precursors include:

  • Communication between and among people
  • Organizational policies relating to job assignments
  • Cognitive biases [Kahneman 2011]
  • Performance management policy
  • Incentive structures
  • Organizational structures
  • Contract language
  • Outsourcing
  • …and approaches to dealing with budget depletion.

Precursors vs. causes

The cables of the Brooklyn Bridge are an example of nonstrategic technical debt
Some of the suspension cables of the Brooklyn Bridge. Washington Roebling, the chief engineer, designed them to be composed of 19 “strands” of wire rope [McCullough 1972]. Each strand had 278 steel wires. Thus, the original design called for a total of 5,282 wires in each of the main cables. After the wire stringing began, the bridge company made an unsettling discovery. The wire supplier, J. Lloyd Haigh, had been delivering defective wire by circumventing the stringent inspection procedures. In all, Roebling estimated that 221 U.S. tons (200 metric tons) of rejected wire had been installed. This was a significant fraction of the planned total weight of 3,400 U.S. tons (3,084 metric tons). Because they couldn’t remove the defective wire, Roebling decided to add about 150 wires to each main cable. That extra wire would be provided at no charge by Haigh [Talbot 2011]. I can’t confirm this, but I suspect that Roebling actually added 152 wires, which would be eight wires for each of the 19 strands. That made a total of 286 wires per strand, or 5,434 wires. The presence of the defective wire in the bridge cables—which remains to this day—is an example of technical debt. The fraud perpetrated by Haigh illustrates how malfeasance can lead to technical debt.
I use the term precursor instead of cause because none of these conditions leads to technical debt inevitably. From the perspective of the policymaker, we can view these conditions as risks. It’s the task of the policymaker to devise policies that manage these risks.

McConnell has classified technical debt in a framework that distinguishes responsible forms of technical debt from other forms [McConnell 2008]. Briefly, we incur some technical debt strategically and responsibly. Then we retire it when the time is right. We incur other technical debt for other reasons, some of which are inconsistent with enterprise health and wellbeing.

The distinction is lost on many. Unfortunately, most technical debt is nonstrategic. We would have been better off  if we had never created it. Or if we had retired it almost immediately. In any case we should have retired it long ago.

It’s this category of nonstrategic technical debt that I deal with in this thread. Although all technical debt is unwelcome, we’re especially interested in nonstrategic technical debt, because it’s usually uncontrolled. In these posts I explore the nontechnical mechanisms that lead to formation of nonstrategic technical debt. Schedule pressure is one exception. Because it’s so important, it deserves a thread of its own. I’ll address it later.

Last words

Here are some of the more common precursors of nonstrategic technical debt.

I’ll be adding posts on these topics, so check back often, or subscribe to receive notifications when they’re available.

References

[Brenner 2016a] Richard Brenner. “The Psychology and Politics of Technical Debt: How We Incur Technical Debt and Why Retiring It Is So Difficult,” Cutter Business Technology Journal, 29:3, 2016, 21-27.

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Hollenbeck 2012] John R. Hollenbeck, Bianca Beersma, and Maartje E. Schouten. “Beyond Team Types and Taxonomies: A Dimensional Scaling Conceptualization for Team Description,” Academy of Management Review, 37:1, 82–106, 2012. doi:10.5465/amr.2010.0181

Available: here; Retrieved: July 8, 2017

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[McConnell 2008] Steve McConnell. Managing Technical Debt, white paper, Construx Software, 2008.

Available: here; Retrieved November 10, 2017.

Cited in:

[McCullough 1972] David McCullough. The Great Bridge: The epic story of the building of the Brooklyn Bridge. New York: Simon and Schuster, 1972.

Order from Amazon

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

[Talbot 2011] J. Talbot. “The Brooklyn Bridge: First Steel-Wire Suspension Bridge.” Modern Steel Construction 51:6, 42-46, 2011.

Available: here; Retrieved: December 20, 2017.

Cited in:

[Woodard 2013] C. Jason Woodard, Narayan Ramasubbu, F. Ted Tschang, and V. Sambamurthy. “Design Capital and Design Moves: the Logic of Digital Business Strategy,” MIS Quarterly 37:2, 537-564, 2013.

Cited in:

Related posts

  • Malfeasance can lead to new technical debt
    Although deploying technical debt management policies is necessary, it might not be sufficient. Malfeasance can lead to incurring new technical debt. It can prevent retiring—or even identifying—existing technical debt. Correcting, detecting, and preventing malfeasance must be goals of technical debt management policy.
  • The Broken Windows theory of technical debt is broken
    Because there is no known controlled study providing evidence that supports the application of the Broken Windows theory to technical debt management, Broken Windows as applied to technical debt management must be regarded as an intriguing conjecture awaiting scientific examination.
  • The Tragedy of the Commons is a distraction
    The urge to control technical debt by designating one group as the “owner” of the asset doesn’t avoid the tragedy of the commons. It leads inevitably to duplication and more technical debt. A more effective approach: Communities that share specific assets must devise customs, rules, and sanctions for managing them.
  • Organizational psychopathy: career advancement by surfing the debt tsunami
    Organizational psychopathy can be the dominant contributing factor in generating technical debt when the primary beneficiary of a decision is the decision maker or the advocate, and when he or she intends to move on to employment elsewhere before the true cost of the debt becomes evident.
  • Contract restrictions can lead to technical debt
    Contract restrictions can lead to technical debt. When contractor organizations customize an asset they own for customers, they usually mean to retain ownership of the asset. But segregating the asset from the customizations can lead to technical debt. Here’s how.
Show Buttons
Hide Buttons