Tag: urgency

Posted on

Non-technical precursors of non-strategic technical debt

Last updated on April 29th, 2018 at 06:36 am

Non-strategic technical debt is technical debt that appears in the asset without strategic purpose. We tend to introduce non-strategic 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 group of posts I examine a variety of precursors of non-strategic technical debt that are not 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.

The cables of the Brooklyn Bridge are an example of non-strategic technical debt
Some of the suspension cables of the Brooklyn Bridge. Washington Roebling, the chief engineer, designed the cables to be composed of 19 “strands” of wire rope [McCullough 1972]. Each strand was to be made of 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 bridge company’s stringent inspection procedures. In all, Roebling estimated that 221 U.S. tons (200 metric tons) of rejected wire had been installed in the bridge. 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, to make a total of 286 wires per strand, for a total of 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, and 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 non-strategic. 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 non-strategic technical debt that I deal with in this group of posts. Although all technical debt is unwelcome, we’re especially interested in non-strategic technical debt, because it is usually uncontrolled. In these posts I explore the non-technical mechanisms that lead to formation of non-strategic technical debt. Schedule pressure is one exception. Because it’s so important, it deserves a thread of its own. I’ll address it later.

Common precursors of non-strategic technical debt

Here are some of the more common precursors of non-strategic technical debt.

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

References

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

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

Related posts

  • Malfeasance can be a source of 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.
Posted on

With all deliberate urgency

Last updated on June 2nd, 2018 at 09:21 pm

One of the drivers of technical debt—one of the most important generators of technical debt—is crossing the fine line from urgency to panic when it comes to deadlines.

On October 12, 2017, the Chicago Cubs and Washington Nationals met at the Nationals’ home field for Game 5 of the National League Divisional Series (American baseball playoffs). At that point, the series was tied 2-2. It was a high-pressure game that would decide the division championship. By the end of the second inning, the Nationals led 4-1. They went on to lose, 9-8.

Pressure situations are tough.

Dusty Baker as Manager of the Washington Nationals in 2017
Dusty Baker (center) as Manager of the Washington Nationals, at a game at the home field of the Baltimore Orioles, May 8, 2017. At the right is Davey Lopes, the first base coach. I can’t identify the man on the left. If you can, let me know. Photo (cc) Keith Allison courtesy Wikimedia
After losing the first game of the series, Dusty Baker, the Nationals’ manager, conducted a press conference before Game 2. A difficult situation for any manager. He’s quoted [Gonzales 2017] as saying, “There’s a fine line between urgency and panic, and the thing that you never want to do, you never want to panic.”

These are words of wisdom that apply just as well in business, especially with respect to technical debt. Consider this scenario:

Sales at Unbelievable Growth, Inc.,(UGI) have been only fair this fiscal year—far from “unbelievable.” But a new product is under development, an app for Android and iPhone called StrawIntoGold 1.0. It has an uncanny ability to predict the price movements of specific common stocks over the next 60 seconds. (This is totally fictitious—don’t bother surfing for UGI or StrawIntoGold) Unfortunately, StrawIntoGold development is far behind schedule. After the all-hands meeting yesterday, the core engineering team had a three-hour meeting of its own. They found some ways to wrap things up in the next ten days. They think they can do it, but they’ll be eliminating some testing, and performing other tests manually. And they plan to re-use some code from the beta version that they had previously decided to replace.

If the UGI engineers succeed, they will be incurring significant technical debt. They have crossed the “urgency line,” and although it’s too soon to say definitively that they’ve panicked, my personal experience suggests that the risk of reaching some degree of panic is high. And that risk will get higher as the deadline approaches.

Urgency focuses our energy and attention. As Dusty Baker says, “You have to be of the coolness of mind, but then bring desire to succeed in your heart, and then respond.” When urgency is deliberate, urgency gets the job done. Deliberate urgency is what Kotter calls healthy urgency [Kotter 2014].

Panic is something else. It can cause us to choose to cut corners, a choice commonly cited as a source of technical debt. When it makes clear thinking difficult, it impedes memory, increases error rates, reduces attention spans, and contributes to toxic conflict. In short, it makes any kind of brainwork more difficult, less effective, and less reliable.

It’s reasonable to suppose that panic isn’t helpful in avoiding or removing technical debt in any kind of technological asset. It’s just as reasonable to suppose that panic actually contributes to technical debt formation and persistence.

Urgency, good. Panic, bad. Once you let panic into an organization’s culture, the effect on technical debt is predictable. Over time, technical debt will increase out of control.

So what alternatives do the UGI engineers have? In most organizations, they would probably have no alternative. StrawIntoGold 1.0 would be offered to customers in a very sorry state that might not affect its performance, but its maintainability—its sustainability—would be poor. The prospects for version 2.0 would not be bright.

But some organizations do find alternative approaches. What they do, in effect, is redefine the word “done” as it applies to the StrawIntoGold 1.0 product. In that redefined form, “done” has two stages.

In Stage 1, UGI does release StrawIntoGold 1.0, despite its unsustainable state. But then UGI management makes a clever decision. Instead of moving the StrawIntoGold team on to begin version 2.0, or what is worse, reassigning the team members to other projects, UGI management charters the StrawIntoGold 1.0 team with retiring the technical debt they incurred to meet the version 1.0 deadline. They restrict the team’s efforts to technical debt retirement only, so that they produce a version 1.1 that is identical to version 1.0 from the customer perspective. That becomes Stage 2 of “done.” They defer any work on version 2.0, because starting 2.0 would cause fragmentation of the 1.0 team. StrawIntoGold 1.0 is thenceforth shelved, and any new orders are filled with StrawIntoGold 1.1. Then work on version 2.0 begins.

By carefully managing their technical debt, UGI can make its products more sustainable in the very dynamic mobile device app market. They exploit urgency deliberately. They do not panic. Then, at UGI, situations like the one that hit StrawIntoGold 1.0 become rare.

Do you have any teams that have crossed the fine line between urgency and panic?

References

[Gonzales 2017] Mark Gonzales. “Nationals manager Dusty Baker preaches calm vs. Cubs,” ChicagoTribune.com, October 7, 2017.

Available: here; Retrieved: December 13, 2017.

Cited in:

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

Order from Amazon

Cited in:

[Kotter 2014] John P. Kotter. “To Create Healthy Urgency, Focus on a Big Opportunity,” Harvard Business Review, February 21, 2014.

Available: here; Retrieved: December 13, 2017.

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:

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

Other posts in this thread

Show Buttons
Hide Buttons