Spontaneous generation

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.

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.

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.

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] A. Lowy and P. 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:

Other posts in this thread

Malfeasance can be a source of technical debt

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

Although creating and deploying policies to manage technical debt is a necessary step, it isn’t sufficient for achieving control in every case. Even if training and communication programs are effective, the possibility of intentional circumvention of technical debt management policy remains. Malfeasance can lead to incurring new technical debt by circumventing any policy. And malfeasance can be an obstacle to retiring—or even identifying—existing technical debt. Moreover, indirect effects of forms of malfeasance seemingly unrelated to technical debt can nevertheless incur technical debt or extend the lifetime of existing technical debt.

Examples of malfeasance as a source of technical debt

Elizabeth Holmes Backstage at TechCrunch Disrupt San Francisco 2014
Elizabeth Holmes Backstage at TechCrunch Disrupt San Francisco 2014. She is the founder, chairman, and CEO of Theranos, a startup that grew to a total valuation of $9 billion in 2015, and has since dramatically declined in value, now on the edge of its second bankruptcy. Theranos, through Holmes, claimed to have developed a technology that enabled blood testing with small amounts of blood—0.1% to 1% of the amount of blood required by conventional blood testing technologies. These claims proved false. After a series of collisions with U.S. government agencies, the U.S. Securities and Exchange Commission sued Holmes and Theranos. In March 2018, a settlement was reached in which Holmes accepted severe financial penalties, loss of voting control of Theranos, and a ban from serving as an officer or director of any public company for ten years. Photo (cc) Max Morse for TechCrunch.

Consider an example from software engineering. To save time, an engineer might intentionally choose to use a deprecated approach. When the malfeasance is discovered, one question naturally arises: in what other places and on what other projects has this individual (or other individuals) been making such choices? In a conventional approach to controlling this form of technical debt, we might be concerned only with the engineer’s current assignment. But a more comprehensive investigation might uncover a trail of technical debt artifacts in the engineer’s previous assignments.

Allman relates a hardware-oriented example [Allman 2012]. He describes an incident involving the University of California at Berkeley’s CalMail system, which failed catastrophically in November 2011, when one disk in a RAID (Redundant Array of Inexpensive Disks) failed due to deferred maintenance. Allman regards this incident as traceable to the technical debt consisting of the deferred RAID maintenance. While this particular case isn’t an example of malfeasance, it’s reasonable to suppose that decisions to defer technical maintenance on complex systems frequently are arguably negligent.

History provides us with many clear examples of malfeasance leading to technical debt indirectly. Consider the Brooklyn Bridge. Many of the suspension cables of the bridge contain substandard steel wire, which was provided to the bridge constructors by an unscrupulous manufacturer. When the bridge engineer discovered the malfeasance, he recognized that the faulty wire that had already been installed could not be removed, or even inspected. So he compensated for the faulty wire by adding additional strands to the affected cables. For more, see “Non-technical precursors of non-strategic technical debt.”

What kinds of malfeasance deserve special attention and why

Malfeasance that leads to incurring technical debt or which extends the life of existing technical debt has the potential to expose the enterprise to uncontrolled increases in operating expenses and unknown obstacles to revenue generation. The upward pressures on operating expenses derive from the MICs associated with technical debt. Although MICs can include obstacles to revenue generation, considering these obstacles separately helps to clarify of the effects of malfeasance.

Malfeasance deserves special attention because the financial harm to the enterprise can dramatically exceed the financial benefit the malfeasance confers on its perpetrators. This property of technical-debt-related malfeasance is what makes its correction, detection, and prevention so important.

For example, when hiring engineers, some candidates claim to have capabilities and experience that they actually don’t have. Once they’re on board, they expose the enterprise to the risk of technical debt creation through substandard work that can escape notice for indefinite periods. The malfeasance here consists of the candidate’s misrepresentation of his or her capabilities. Although the candidate, once hired, does receive some benefit arising from the malfeasance, the harm to the enterprise can exceed that benefit by orders of magnitude.

As a second example, consider the behavior of organizational psychopaths [Babiak 2007] [Morse 2004]. Organizational psychopathy can be a dominant contributing factor to technical debt formation when the primary beneficiary of a proposed strategy is the decision-maker or the advocate who takes credit for the short term effects of the decision, and when he or she intends knowingly to move on to a new position or to employment elsewhere before the true long term cost of the technical debt becomes evident. This behavior is malfeasance of the highest order. And although it’s rare, its impact can be severe. For more, see “Organizational psychopathy: career advancement by surfing the debt tsunami.”

What’s required to control malfeasance

When a particular kind of malfeasance can incur technical debt or extend the life of existing technical debt, it merits special attention. Examples like those above suggest three attributes that technical debt management programs must have if they are to deal effectively with malfeasance.

Corrective measures

Corrective measures can be undertaken in a straightforward manner when inadvertent policy violations occur. For example, unexpected difficulties in setting priorities for technical debt retirement efforts might be the result of individual performance metrics that conflict with the technical debt control program. Such conflicts can be inadvertent and can be resolved collaboratively.

But with regard to malfeasance, difficulties arise when policy violations are discovered or reported. When the violations are intentional, corrective action usually entails investigation of the means by which the infraction was achieved, and the means by which it was concealed. When these activities involve many individuals attached to multiple business units, some means of allocating the cost of corrective action might be needed. Allocating the cost of corrections can also be difficult when one party has reaped extraordinary benefits by taking steps that led to incurring significant technical debt. In some cases, corrective measures might include punitive actions directed at individuals.

Detection measures

When intentional violations are covert, or those who committed the violations claim that they’re unintentional, investigation is necessary to determine whether or not a pattern of violations exists. Technical debt forensic activities require resources, including rigorous audits and robust record-keeping regarding the decisions that led to the formation or persistence of technical debt. Automated detection techniques might be necessary to control the cost of detection efforts, and to ensure reliable detection.

Preventative measures

Successful prevention of policy violations requires education, communication, and effective enforcement. The basis of effective policy violation prevention programs includes widespread understanding of the technical debt concept and the technical debt management policies, and the certainty of discovery of intentional infractions. These factors require commitment and continuing investment.

Policy frameworks are at risk of depressed effectiveness if they pay too little attention to malfeasance and other forms of misconduct. Such misbehavior deserves special attention because it’s often accompanied both by attempts to conceal any resulting technical debt, and attempts to mislead investigators and managers about its existence. These situations do arise, though rarely, and when they do, they must be addressed in policy terms.

References

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

Available: here; Retrieved February 26, 2017.

Cited in:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

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] A. Lowy and P. 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:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

Other posts in this thread

The Broken Windows theory of technical debt is broken

In the United States, the Broken Windows theory of crime control first appeared in the public conversation in 1982, when Kelling and Wilson described it in The Atlantic (then known as The Atlantic Monthly) [Kelling 1982]. Briefly, the theory suggests that in urban environments, by applying police resources to preventing small crimes such as vandalism, public drinking, and toll jumping, one can prevent serious crime and create an atmosphere of order and lawfulness. Gladwell popularized the idea in his explosive best seller The Tipping Point [Gladwell 2000].

Broken windows in an old abandoned factory
Broken windows in an old abandoned factory. To work in an environment dominated by properties like this must certainly be demoralizing. But whether existing technical debt actually causes people to make choices that incur new technical debt is another question. At this point, it’s an open question.

In the year before Gladwell’s work appeared, Hunt and Thomas incorporated the Broken Windows theory into their work, The Pragmatic Programmer, suggesting it as a justification for the importance of retiring technical debt immediately upon discovering it [Hunt 1999]. Briefly, the theory as applied to technical debt in software is that tolerating low quality and technical debt in a given asset encourages further degradation of quality and incurring additional technical debt. Within the software community, the Broken Windows theory of managing technical debt is widely accepted [Note a].

However, between Kelling’s work in 1982 and the work of Hunt and Thomas in 1999, criminologists and sociologists had become skeptical of the Broken Windows theory as applied to crime prevention. As far back as 1998, investigations had begun to cast doubt on the Broken Windows theory [Harcourt 1998]. In 2006, Eck and Maguire assembled a review of the escalating controversy [Eck 2006]. Research by O’Brien, Sampson, and Winship, based on “big data” analyses, failed to produce evidence of validity of the Broken Windows theory beyond a weak positive correlation between social orderliness and lawful behavior [O’Brien 2015]. Indeed, their research instead showed a very strong positive correlation between private violent behavior and major crimes. Others have noted that what appeared to be positive results for the application of the Broken Windows approach to crime prevention in the 1990s was actually explainable by other phenomena [Note b].

Social scientists and criminologists have taken these findings seriously enough to have founded the Center for Evidence-Based Crime Policy at George Mason University, which maintains an evidence-based policing matrix to assist law enforcement organizations in evaluating the validity of claims about the efficacy of specific tactics and strategies, such as the Broken Windows theory. (See their review of Broken Windows Policing.)

But even as doubts developed about the efficacy of Broken Windows policing for crime prevention, Broken Windows continued to find adherents relative to managing technical debt in software assets. The software engineering community thus finds itself, perhaps, in the same position with respect to Broken Windows as it is with respect to the Tragedy of the Commons. Broken Windows and the Tragedy of the Commons are both fine analogies, but the fields that originated them now have superior ways of understanding the phenomena in question.

Maybe it’s time for the engineering community to re-examine Broken Windows as it pertains to technological asset quality and technical debt. At this time, the author is aware only of anecdotal support for the Broken Windows theory of technical debt management. Perhaps the Broken Windows theory will work better in engineering than it did in social science or criminology, but do you want to bet your company on that?

References

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

Available: here; Retrieved February 26, 2017.

Cited in:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

Order from Amazon

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

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:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Lowy 2004] A. Lowy and P. 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:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

Other posts in this thread

The Tragedy of the Commons is a distraction

Last updated on July 24th, 2018 at 08:19 pm

Many believe that technical debt arises, in part, because of a phenomenon known as the Tragedy of the Commons [Hardin 1968], which is an allegory that purports to demonstrate that the user communities associated with shared resources inevitably degrade those resources until they’re depleted. The allegory supposedly supports the thesis that only monocratic control of an asset can provide the strict regulation that prevents its inevitable degradation as a result of shared use. Advocates of this approach to limiting the degradation arising from the expansion of technical debt hold that assigning sole ownership of resources, resource by resource, is the only effective method of controlling technical debt.

A map of the Boston Common and Public Garden, circa 1890. This is the kind of “common” referred to in the tragedy of the commons.
A map of the Boston Common and Public Garden, circa 1890. By that time it was basically a park. But as late as 1830 it was still being used as a cow pasture. They didn’t have refrigeration at the home scale then, except by ice blocks, and the best way to get fresh dairy products was to have a cow. In the very early days, 1633-1640, anyone could graze on the Common, but as wealthy people acquired more animals, the common became overgrazed, and a 70-cow limit was imposed. That limit stood until 1830. It’s an example of a method for managing a shared resource. This map is from an atlas of Boston published by G.W. Bromley & Co.,, courtesy Wikimedia Commons
The resources in question here are the assets that tend to accumulate, or are accumulating, or have accumulated, technical debt. Adherents of the theory would impose order by dividing each technological asset into one or more sectors, sometimes called development silos, with only one organizational unit designated as the “owner,” empowered to develop, maintain, or extend that sector [Bossavit 2013] [Morris 2012]. Irreconcilable disagreements about the direction or purpose of a particular sector of the asset presumably would be resolved by branching.

Ironically, such an approach would — and demonstrably does — produce significant technical debt in the form of duplication of artifacts and services. Moreover, it elevates costs relative to a truly shared asset, by reducing sharing, and increasing the need for testing. We can regard such an approach as dysfunctional conflict avoidance [Brenner 2016b].

Although at one time the Tragedy of the Commons was regarded as a universally valid concept in political economics, subsequent research has demonstrated that the principle it describes is not generally applicable. Hardin first described the Tragedy of the Commons in 1968, in the form of an allegory [Hardin 1968]. In his words:

Picture a pasture open to all. It is to be expected that each herdsman will try to keep as many cattle as possible on the commons. Such an arrangement may work reasonably satisfactorily for centuries because tribal wars, poaching, and disease keep the numbers of both man and beast well below the carrying capacity of the land. Finally, however, comes the day of reckoning, that is, the day when the long-desired goal of social stability becomes a reality. At this point, the inherent logic of the commons remorselessly generates tragedy.

As a rational being, each herdsman seeks to maximize his gain. Explicitly or implicitly, more or less consciously, he asks, “What is the utility to me of adding one more animal to my herd?”

Hardin then explains that each herdsman is compelled by the logic of the situation to exploit the shared resource to the maximum. Each herdsman puts his own interests ahead of the welfare of the resource.

And so it goes, supposedly, with technical debt. Each user of the shared asset expends resources on development, maintenance, and enhancement only to the extent that the expenditure is justified by immediate need. Retiring any legacy technical debt, or any technical debt accumulated in the course of meeting those immediate needs, is regarded as low priority. Because resources for debt retirement are rarely if ever sufficient to meet the need, technical debt grows inexorably. Eventually, the shared asset becomes unmaintainable and must be abandoned.

However, careful research shows that Hardin’s Commons allegory is not applicable to every situation involving shared resources. That same research casts doubt on the validity of the assertion that development silos are necessary in any approach to technical debt management.

Certainly there are many examples of shared resources degrading along the lines outlined by Hardin, such as the collapse of the Northwest Atlantic cod fishery [Frank 2005], but many counterexamples exist. Research by the late political economist Elinor Ostrom uncovered numerous examples of complex social schemes for maintaining common resources efficiently and sustainably [Ostrom 2009] [Ostrom 1990]. Ostrom studied and reported on systems that successfully managed shared resources over long terms — in some cases, centuries. For this work, she received the Nobel Prize in Economics in 2009.

As Ostrom’s research demonstrated, the problem with Hardin’s allegory is that it applies only to shared resources that are open to use by all without regulation. The misapplication of the Tragedy of the Commons is clearly described in a World Bank Discussion Paper by Bromley and Cernea [Bromley 1989]:

For some time now, Hardin’s allegory of the “tragedy” has had remarkable currency among researchers and development practitioners. Not only has it become the dominant paradigm within which social scientists assess natural resource issues, but it appears explicitly and implicitly in the formulation of many programs and projects and in other beliefs and prejudices derived from it. Unfortunately, its power as a metaphor is not matched by its capacity for aiding our understanding of resource management regimes. By confusing an open access regime (a free-for-all) with a common property regime (in which group size and behavioral rules are specified) the metaphor denies the very possibility for resource users to act together and institute checks and balances, rules and sanctions, for their own interaction within a given environment.

Hardin himself later published an extension of the allegory that clarified the role of regulation [Hardin 1998], as had been observed much earlier by Lloyd [Lloyd 1833].

The real tragedy for technology managers would be their failure to learn from the past errors of social scientists and political economists, and to then repeat, in the context of technical debt management, this now well-understood confusion about the domain of applicability of Hardin’s allegory.

We can apply Ostrom’s result to the problem of managing technical debt if we identify the technical asset as the shared resource, and identify as the community exploiting the resource the stakeholders who employ, develop, maintain, cyber-defend, or extend that technical asset. Ostrom’s results tell us that sustainable exploitation is possible only if the community devises rules, customs, and sanctions that manage the technical debt. Kim and Wood [Kim 2011] provide an analysis that explains how regulation can avert depletion scenarios. Technology managers can apply these lessons to the problem of managing technical debt.

The Tragedy of the Commons is a distraction because technical debt isn’t an inevitable result of sharing assets when the organization adheres to a Principle of Sustainability. That principle is that sustainability is possible only if the community sharing the asset devises customs, rules, and sanctions that effectively control the level of technical debt. You just can’t have a free-for-all unregulated regime, as most organizations now do. Management and practitioners must collaborate to devise the customs, rules, and sanctions for managing the asset. And regular updating is probably necessary. Leadership in devising those customs, rules, and sanctions is a job for the policymaker.

References

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

Available: here; Retrieved February 26, 2017.

Cited in:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

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:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Lowy 2004] A. Lowy and P. 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:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[Ostrom 1990] Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Ostrom, Elinor. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

Other posts in this thread

Organizational psychopathy: career advancement by surfing the debt tsunami

Last updated on July 24th, 2018 at 08:23 pm

During policy debates, some decision-makers and some advocates take positions that offer short-term advantages to the enterprise at the expense of incurring heavy burdens of new technical debt or allowing legacy technical debt to remain in place. Some of these decisions can be strategic, and they can benefit the enterprise. But organizational psychopathy can be the dominant contributing factor when the primary beneficiary of the strategy is the decision-maker or the advocate, and when he or she intends knowingly to move on to a new position or to employment elsewhere before the true cost of the technical debt becomes evident.

The aftermath of the 2004 Indian Ocean earthquake, 26 December 2004
The aftermath of the 2004 Indian Ocean earthquake and tsunami, 26 December 2004. Shown is what remained of Meulaboh, Sumatra, Indonesia, after it was hit by the tsunami. The photo was taken on January 10. At the lower left is a Landing Craft Air Cushion (LCAC) hovercraft vehicle, assigned to USS Bonhomme Richard, delivering supplies. LCACs are capable of transporting more supplies than helicopters in a single trip. The technical debt devastation left behind after an organizational psychopath moves on to further conquests can be just as overwhelming as the physical devastation left behind after a tsunami. Photo by U.S. Navy courtesy Wikimedia Commons.
Such decisions can be counterproductive for the enterprise in the long term. But the decision-maker or advocate nevertheless favors the decision, because he or she plans to take credit for the short-term benefits, and then move on to a new career position elsewhere to escape the technical debt problems created by the decision. In effect, the decision-maker or advocate plans to “surf the debt tsunami.”

People who adopt strategies of this kind might be following the pattern of organizational psychopathy [Babiak 2007] [Morse 2004]. Organizational psychopaths compulsively seek power and control over others. They use a vast array of tactics, but the tactic of greatest relevance to this discussion is the use of enterprise resources to advance the psychopath’s career. Technical debt provides a mechanism for borrowing future resources to enhance present performance, thus advancing the career of the psychopath. It’s especially attractive to the psychopath because the harmful consequences of technical debt can remain hidden until the psychopath has long ago moved on.

Psychopaths are better equipped than most to execute such strategies, because they can be exceedingly charming, intelligent, and charismatic. Because they are adept at deception, they are willing to conceal the truth about the technical debt they create, misrepresenting its costs and consequences, or concealing it altogether. Most important, organizational psychopaths seem to lack the internal regulators of conscience and compunction that limit the actions of non-psychopaths. For example, in a debate about a specific technical decision, the psychopath is willing to use any tools available to win the point, including using deception to destroy the career of anyone who challenges the psychopath’s position.

Babiak and Hare estimate that the incidence of psychopathy in senior positions in business is about 3-4% — between 1/30 and 1/25. However, I’m unaware of any studies of the strategic use of technical debt by these individuals. It’s reasonable to suppose that technical debt has been so employed, but the significance of this phenomenon is unknown. Serious investigation is in order.

References

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

Available: here; Retrieved February 26, 2017.

Cited in:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

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:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Lowy 2004] A. Lowy and P. 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:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[Ostrom 1990] Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Ostrom, Elinor. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

Other posts in this thread

Contract restrictions can lead to technical debt

Last updated on March 22nd, 2018 at 11:18 pm

When the owner of an asset, especially a software asset, contracts to provide a capability to a customer incorporating a use of that asset, the work involved might require modification or enhancement of that asset. When the contract permits such work, without transferring ownership of the asset itself, performing it is relatively straightforward, provided the work can be done in a manner compatible with any pre-existing or anticipated future other uses of the asset. But some contract restrictions can cause the owner of the asset to incur technical debt.

A power adaptor/converter for international travelers with U.S. standard equipment.
A power adaptor/converter for international travelers with U.S. standard equipment. This device provides conversion for both hardware connection and voltage supplied.
The wide variation in electric power standards worldwide can be viewed as a technical debt. Someday, in the probably distant future, a world standard will emerge and that debt will be retired. Until then, adaptors like these are travel necessities.

But some contracts restrict such work. For example, for a government customer, ownership of the work performed might be required to transfer to the government customer. Potentially, all of the work might be classified as a national secret. In either of these cases, to retain control of the asset, the owner/contractor arranges to perform all of the work outside the periphery of the asset. To accomplish this, the owner/contractor might interface to the asset through an adaptor that can be transferred to the government customer, or which can be classified as secret as the case may be, thereby insulating the original asset from these ownership restrictions.

The result is tolerable after one such contract is completed. But over time, as the number of adaptors increases, they become a form of technical debt. Each must be maintained against any changes in the original asset. Moreover, making changes to the original asset can become a project of such scale that the temptation to create a static “clone” of the asset for each customer is irresistible. When that happens, any technical debt already present in the asset is also cloned. And any work performed to correct defects in the asset must be performed on each affected clone.

The problem is more general than suggested above. It also appears in the case of software offered for multiple platforms, or multiple versions of a single platform.

But it gets worse. Suppose the maintainers decide to update the asset to make it more extensible, or to make it more maintainable. That update, including all testing and documentation, must then be performed on each clone. If the asset owner elects not to update all clones, then the clones will begin to diverge from each other. Engineers performing tasks on one of the clones must then have knowledge of how it differs from other clones. If a new defect is discovered, it might or might not be present in every clone. Implementing a new extension or other modification might not be possible in all clones, or it might have to be implemented differently in some clones. Life can get very complicated.

Organizations entering into contracts of this kind would be wise either to include language limiting their obligations to maintain the original asset against any changes, internal or external, in its ability to perform its functions. Or they might include an explicit statement of the parties’ intentions relative to financial support for any continuing obligations to maintain that asset.

Organizations offering products for multiple platforms would be wise to consider as strategic the management of technical debt that arises from platform multiplicity. Sound management of this form of technical debt can extend their ability to support multiple platforms, which can dramatically increase returns on investment in the core asset.

References

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

Available: here; Retrieved February 26, 2017.

Cited in:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

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:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Lowy 2004] A. Lowy and P. 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:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[Ostrom 1990] Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Ostrom, Elinor. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

Other posts in this thread

How budget depletion leads to technical debt

Some projects undergo budget depletion exercises when their budgets are reduced, or when there’s evidence that the funds remaining will be insufficient to complete the work originally planned. Formats vary, but the typical goal of these exercises is downscoping — removing, relaxing, deferring, or suspending some requirements. Since funds are limited, downscoping is often executed in a manner that leads to technical debt.

The Old River Control Complex on the Mississippi River
The Old River Control Complex on the Mississippi River. Built and operated by the US Army Corps of Engineers (USACE) the Old River Control Complex is used for controlling the flow from the Mississippi into a distributary known as the Atchafalaya River. Were it not for this facility, the Mississippi would long ago have rerouted itself into the Atchafalaya, which has a much steeper gradient to the ocean. Since that change would have deprived New Orleans and all the industrial facilities along the lower Mississippi of access to the water and navigational channels they now enjoy, USACE maintains a complex of flow control facilities to prevent Nature taking its course, and to prevent flooding along the lower Mississippi.
The industrial facilities of the lower Mississippi constitute a technical debt, in the sense that their existence is no longer compatible with the “update” Nature is trying to deploy, in the form of rerouting the flow of water from the Mississippi to the Atchafalaya. Because our national budget doesn’t allow for repositioning the city of New Orleans and all the industrial facilities from the lower Mississippi to somewhere along the Atchafalaya, we’ve elected to redirect the flow of water from the course Nature prefers to a course more compatible with the existing industrial base. Operating and maintaining the Old River Control Complex, together with a multitude of levees, dredging projects, and gates throughout lower Louisiana, are the MICs we pay for the technical debt that is the outdated position of the city of New Orleans and its associated industrial base.
For more about Atchafalaya, see the famous New Yorker article by John McPhee [MacFee 1987]. Photo courtesy USACE
Here’s an illustrative scenario. At the time downscoping begins, the work product might contain incomplete implementations of items that are to be removed from the list of objectives. A most insidious type of debt, and most difficult to detect, consists of accommodations contained in surviving artifacts that are no longer needed because the items they were intended to support have been cancelled. This class of technical debt is difficult to detect because the affected system components appear to be merely overly complicated. Recognizing it as a residual of a cancelled capability requires knowledge of its history. Unless these artifacts are documented at the time of the downscoping, that knowledge may be lost.

Other items of technical debt that arise from budget depletion include tests that no longer need to be executed, or documentation that’s no longer consistent with the rest of the work product, or user interface artifacts no longer needed. When budgets become sufficiently tight, funds aren’t available for documenting these items of technical debt as debt, and the enterprise can lose track of them when team members move on or are reassigned.

In some instances, budget depletion takes effect even before the work begins. This happens, for example, when project champions unwittingly underestimate costs in order to obtain approval for the work they have in mind. The unreasonableness of the budget becomes clear soon after the budget is approved, and the effects described above take hold soon thereafter.

Budget depletion can also have some of the same effects as schedule pressure. When the team devises the downscoping plan, it must make choices about what to include in the revised project objectives. In some cases, the desire to include some work can bias estimates of the effort required to execute it. If the team underestimates the work involved, the result is increased pressure to perform that work. With increased pressure comes technical debt. See “With all deliberate urgency” for more.

A policy that could limit technical debt formation in response to budget depletion would require identifying the technical debt such action creates, and later retiring that debt. Because these actions do require resources, they consume some of the savings that were supposed to accrue from downscoping. In some cases, they could consume that amount in its entirety, or more. Most decision-makers probably over-estimate the effectiveness of the downscoping strategy. Often, it simply reduces current expenses by trading them for increased technical debt, which raises future expenses and decreases opportunities in future periods.

References

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

Available: here; Retrieved February 26, 2017.

Cited in:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

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:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Lowy 2004] A. Lowy and P. 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:

[MacFee 1987] John MacFee. “Atchafalaya,” The New Yorker, February 23, 1987.

Available: here; Retrieved: February 5, 2018.

Cited in:

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

Available: here; Retrieved November 11, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[Ostrom 1990] Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Ostrom, Elinor. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

Other posts in this thread

How outsourcing leads to increasing technical debt

Most of the non-technical precursors of technical debt that afflict in-house work also afflict outsourced work. For example, the planning fallacy affects internal planners, but it also afflicts the bidders for contracts offered by the enterprise in the context of outsourcing. As described in “Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma,” Boehm, et al., [Boehm 2016] call this the “Conspiracy of Optimism.” But outsourcing engineering work can introduce pathways for incurring technical debt that are specific to outsourcing.

Green fields
Green fields. Greenfield outsourcing, also known as startup outsourcing, is the outsourcing of activity that has never been performed within the enterprise. It’s especially tricky with respect to technical debt formation, because much of the expertise necessary to perform the work being outsourced is probably not resident within the enterprise. That void in enterprise expertise makes for difficulties in managing technical debt in the outsourced artifacts.

The risks of incurring technical debt associated with outsourcing are inherently elevated, even setting aside those factors that also afflict in-house activity. When most enterprises contract for development of systems or software, the criteria for acceptance rarely include specifications for maintainability or extensibility. This happens, in part, because such qualitative specifications are so difficult to define quantitatively. That’s why the condition of deliverables relative to maintainability and extensibility is so variable. Outsourced deliverables can best be described as bearing an unknown level of technical debt.

The root cause of the problem is likely a lack of a universally accepted metrics for quantifying technical debt [Li 2015]. That’s why it’s difficult to specify in the vendor contract an acceptability threshold for technical debt. And since the consequences of the presence of technical debt in deliverables potentially do not become clear during the lifetime of the contract under which the debt was incurred, years may pass before the issue becomes evident, which complicates the task of understanding the root cause of the problem.

In what follows, I use the term vendor to denote the organization to which work has been outsourced, and the term enterprise to denote the organization that has outsourced a portion of its engineering work. The retained organization is the portion of the enterprise directly relevant to the outsourced work, but which was not itself outsourced. Among the mechanisms that lead to incurring technical debt in the outsourcing context are the six mechanisms sketched below. Gauging the size of these effects by auditing deliverables or by auditing the internal processes of the vendor could be helpful in managing levels of technical debt arising from outsourcing.

This list isn’t intended to be exhaustive. Quite possibly other phenomena also contribute to technical debt formation in the context of outsourcing.

Progressive erosion of retained organization capabilities

Over time, the enterprise can expect erosion of the engineering expertise needed to manage, evaluate, understand, or, if need be, to re-insource (or backsource) the work that has been outsourced [Willcocks 2004][Beardsell 2010]. Typically, staff who formerly performed the outsourced work do move on to other work, voluntarily or not, either within the enterprise or elsewhere. Indeed, cost savings from terminations and employee buyouts often accompany — and economically justify — outsourcing decisions. But even if the enterprise continues to employ the people who formerly performed the work that is now outsourced, those employees, filling new roles, can become less familiar with the current work and therefore less able to perform it. And since they are now engaged in other assignments, their availability is limited. In the public sector, the organizations that perform the outsourced work exacerbate this phenomenon by recruiting from the agencies they serve [Kusnet 2007]. In manufacturing, Kinkel et al. suggest that, paraphrasing, outsourcing disturbs the formation of internal competence [Kinkel 2016].

In short, outsourcing engineering efforts can erode the ability of the enterprise to perform internally the work that is outsourced, or to monitor or evaluate it when performed by the vendor. Consequently, the enterprise is less able to monitor, evaluate, or retire any technical debt that accumulates in the outsourced work products. A policy that would address this risk is one that would (a) require retained organizational capability sufficient to assess the effect on technical debt of any outsourced engineering work; (b) require attention to technical debt issues in any financial models used in making the initial outsourcing decision; (c) require financial models to include the effects of technical debt and controlling technical debt when deciding whether to extend outsourcing contracts with vendors.

Stovepiping among vendors

Most multi-vendor efforts use a separation-of-concerns approach [Laplante 2007] to dividing the work. That is, each vendor is empowered to use any approach it can, consistent with its own contract and statement of work. In some cases, two or more vendors might have overlapping needs that cause them each to produce similar capabilities as elements of their respective deliverables. Sharing of their results is of course possible, but unless both of their contracts anticipate the need for sharing, sharing is unlikely. Failure to share those results that could have been shared can lead to incurring unrecognized technical debt.

Stovepiping within vendors

With regard to the efforts of a single outsource vendor, it’s possible that different teams or individuals working for that vendor might unwittingly create elements with overlapping capabilities. That duplication could lead to technical debt, or it could constitute technical debt in itself. For example, two teams working for the same vendor might have similar testing needs, and might develop testing tools independently. As a second example, in a version of stovepiping combined with temporal displacement, suppose that one team is unaware that a previous effort for the same customer had already developed a capability that it now needs. That team then might re-create that already-existing capability.

Stovepiping within vendors is less likely when the vendor operates under a single vendor technical lead, and the enterprise interacts with that single lead through a single in-house technical lead. When either side of the relationship is managed through multiple contacts, stovepiping is more likely, and new technical debt is more likely to form.

Loss of continuity in the outsourced engineering staff

Unless specified in the agreement between the vendor and the enterprise, staff turnover or reassignment within the vendor organization, between one version of the product or service and the next, can lead to technical debt in just the same way that turnover in-house can lead to technical debt. With outsourcing, however, the vendor has little internalized motivation to control this phenomenon, and the enterprise likely has less control—and less awareness—of staff assignments within the vendor organization than it does within the enterprise. Thus, loss of continuity in the outsourced engineering staff is both more likely and more likely to lead to technical debt.

Reduced coordination of engineering approaches and business objectives

Lack of coordination between engineering approaches and business planning can cause engineers to create and deploy artifacts that must be revisited later, when they learn of business plans that were unknown to the engineers at the time they produced those artifacts. See “Failure to communicate long-term business strategy.” This scenario is more likely, and possibly irresolvable, when the enterprise withholds its long-term plans from the outsourcing vendor to protect its strategy.

Hiring and retention problems

In some instances, commonly called startup outsourcing or greenfield outsourcing, the work being outsourced has never been performed within the enterprise [Delen 2007]. In these cases, typically, the enterprise must then reassign existing employees or hire new employees to interface with the outsource vendor. These roles are analogous to remote supervisors, except that the teams they supervise are not employees of the enterprise. Hiring and retaining people for these roles can be difficult, because of startup challenges both within the enterprise and within the vendor organization. Recruitment and especially retention problems in these roles can decrease the likelihood of controlling technical debt, and increase the likelihood of incurring 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:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

Order from Amazon

Cited in:

[Beardsell 2010] Julie Beardsell. “IT Backsourcing: is it the solution to innovation?”, SMC Working Paper Series, Issue: 02/2010, Swiss Management Center University, 2010.

Available: here; Retrieved: February 15, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Delen 2007] Guus Delen. “Decision and Control Factors for IT-sourcing,” in Handbook of Network and System Administration, Jan Bergstra and Mark Burgess, eds., Boston: Elsevier, 929-946 (2007).

Order from Amazon

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

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:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Kinkel 2016] Steffen Kinkel, Angela Jäger, Djerdj Horvath, and Bernhard Rieder. “The effects of in-house manufacturing and outsourcing on companies’ profits and productivity,” 23rd International Annual EurOMA Conference, At Trondheim, Volume: 23, June 2016.

Cited in:

[Kusnet 2007] David Kusnet. “Highway Robbery II,” report of the National Association of State Highway and Transportation Unions (NASHTU).

Cited in:

[Laplante 2007] Phillip A. Laplante. What Every Engineer Should Know About Software Engineering. New York: CRC Press, 2007.

Order from Amazon

Cited in:

[Li 2015] Z. Li, P. Avgeriou, and P. Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Lowy 2004] A. Lowy and P. 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:

[MacFee 1987] John MacFee. “Atchafalaya,” The New Yorker, February 23, 1987.

Available: here; Retrieved: February 5, 2018.

Cited in:

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

Available: here; Retrieved November 11, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[Ostrom 1990] Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Ostrom, Elinor. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Willcocks 2004] L. Willcocks, J. Hindle, D. Feeny, and M. Lacity. “IT and Business Process Outsourcing: The Knowledge Potential,” Information Systems Management 21(3), (2004), 7-15.

Cited in:

Other posts in this thread

Confirmation bias and technical debt

Confirmation bias is a cognitive bias [Kahneman 2011]. It’s the human tendency to favor and seek only information that confirms our preconceptions, or to avoid information that disconfirms them. For example, the homogeneity of cable news channel audiences, and the alignment between preconceptions of the audience and the slant of the newscast for that channel, are results of confirmation bias.

Third stage ignition, sending the Mars Climate Orbiter (MCO) to Mars in December, 1998
Computer-generated image of the third stage ignition, sending the Mars Climate Orbiter (MCO) to Mars in December, 1998. The spacecraft eventually broke up in the Martian atmosphere as a result of what is now often called the “metric mix-up.” The team at Lockheed Martin that constructed the spacecraft and wrote its software used Imperial units for computing thrust data. But the team at JPL that was responsible for flying the spacecraft was using metric units. The mix-up was discovered after the loss of the spacecraft by the investigation panel established by NASA.
One of the many operational changes deployed as a result of this loss was increased use of reviews and inspections. While we do not know why reviews and inspections weren’t as thorough before the loss of the MCO as they are now, one possibility is the effects of confirmation bias in assessing the need for reviews and inspections. Image courtesy Engineering Multimedia, Inc., and U.S. National Aeronautics and Space Administration
Confirmation bias causes technical debt by biasing the information on which decision makers base decisions involving technical debt. Most people in these roles have objectives they regard as having priority over eliminating technical debt. This causes them to bias their searches for information about technical debt in favor of information that would support directly the achievement of those primary objectives. They tend, for example, to discount warnings of technical debt issues, to underfund technical debt assessments, and to set aside advice regarding avoiding debt formation in current projects.

For example, anyone determined to find reasons to be skeptical of the need to manage technical debt need only execute a few Google searches. Searching for there is no such thing as technical debt yields about 300,000 results at this writing; technical debt is a fraud about 1.6 million; and technical debt is a bad metaphor about 3.7 million. Compare this to technical debt which yields only 1.6 million. A skeptic wouldn’t even have to read any of these pages to come away convinced that technical debt is at best a controversial concept. This is, of course, specious reasoning, if it’s reasoning at all. But it does serve to illustrate the potential for confirmation bias to contribute to preventing or limiting rational management of technical debt.

Detecting confirmation bias in oneself is extraordinarily difficult because confirmation bias causes us to (a) decide not to search for data that would reveal confirmation bias; and (b) if data somehow becomes available, to disregard or to seek alternative explanations for it if that data tends to confirm the existence of confirmation bias. Moreover, another cognitive bias known as the bias blind spot causes individuals to see the existence and effects of cognitive biases much more in others than in themselves [Pronin 2002].

Still, the enterprise would benefit from monitoring the possible existence and effects of confirmation bias in decisions with respect to allocating resources to managing technical debt. Whenever decisions are made, we must manage confirmation bias risk.

References

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

Available: here; Retrieved February 26, 2017.

Cited in:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

Order from Amazon

Cited in:

[Beardsell 2010] Julie Beardsell. “IT Backsourcing: is it the solution to innovation?”, SMC Working Paper Series, Issue: 02/2010, Swiss Management Center University, 2010.

Available: here; Retrieved: February 15, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Delen 2007] Guus Delen. “Decision and Control Factors for IT-sourcing,” in Handbook of Network and System Administration, Jan Bergstra and Mark Burgess, eds., Boston: Elsevier, 929-946 (2007).

Order from Amazon

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

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:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

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

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Kinkel 2016] Steffen Kinkel, Angela Jäger, Djerdj Horvath, and Bernhard Rieder. “The effects of in-house manufacturing and outsourcing on companies’ profits and productivity,” 23rd International Annual EurOMA Conference, At Trondheim, Volume: 23, June 2016.

Cited in:

[Kusnet 2007] David Kusnet. “Highway Robbery II,” report of the National Association of State Highway and Transportation Unions (NASHTU).

Cited in:

[Laplante 2007] Phillip A. Laplante. What Every Engineer Should Know About Software Engineering. New York: CRC Press, 2007.

Order from Amazon

Cited in:

[Li 2015] Z. Li, P. Avgeriou, and P. Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Lowy 2004] A. Lowy and P. 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:

[MacFee 1987] John MacFee. “Atchafalaya,” The New Yorker, February 23, 1987.

Available: here; Retrieved: February 5, 2018.

Cited in:

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

Available: here; Retrieved November 11, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[Ostrom 1990] Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Ostrom, Elinor. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Pronin 2002] Emily Pronin, Daniel Y. Lin, and Lee Ross. “The bias blind spot: Perceptions of bias in self versus others.” Personality and Social Psychology Bulletin 28.3 (2002): 369-381.

Available: here; Retrieved: July 10, 2017

Cited in:

[Willcocks 2004] L. Willcocks, J. Hindle, D. Feeny, and M. Lacity. “IT and Business Process Outsourcing: The Knowledge Potential,” Information Systems Management 21(3), (2004), 7-15.

Cited in:

Other posts in this thread

Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma

Last updated on September 20th, 2018 at 03:51 pm

In a 1977 report, Daniel Kahneman and Amos Tversky identify one particular cognitive bias [Kahneman 2011], the planning fallacy, which afflicts planners [Kahneman 1977] [Kahneman 1979]. They discuss two types of information planners use. Singular information is specific to the case at hand; distributional information is drawn from similar past efforts. The planning fallacy is the tendency of planners to pay too little attention to distributional evidence and too much to singular evidence, even when the singular evidence is scanty or questionable. Failing to harvest lessons from the distributional evidence, which is inherently more diverse than singular evidence, the planners tend to underestimate cost and schedule. So for any given project, there’s an inherent tendency in human behavior to promise lower costs, faster delivery, and greater benefits than anyone can reasonably expect.

Aerial view of Hoover Dam, September 2017
Aerial view of Hoover Dam, September 2017. Under construction from 1931 to 1936, the dam was built for $48.8M ($639M in 2016 dollars) under a fixed-price contract. It was completed two years ahead of schedule. Apparently the planning fallacy doesn’t act inevitably. 112 men died in incidents associated with its construction. 42 more died of a condition diagnosed as pneumonia, but which is now thought to have been carbon monoxide poisoning due to poor ventilation in the dam’s diversion tunnels during construction. There’s little doubt that unrealistic optimism affects not only projections of budget and schedule, but also projections of risks, including deaths. Photo (cc) Mariordo (Mario Roberto Durán Ortiz), courtesy Wikimedia Commons.
But the problem is exacerbated by a dynamic described by Boehm et al. [Boehm 2016], who observe that because organizational resources are finite, project sponsors compete with each other for resources. They’re compelled by this competition to be unrealistically optimistic about their objectives, costs, and schedules. Although Boehm et al. call this mechanism the “Conspiracy of Optimism,” possibly facetiously, it isn’t actually a conspiracy. Rather, it’s a variant of the N-Person Prisoner’s Dilemma [Hamburger 1973].

Unrealistic optimism creates budget shortfalls and schedule pressures, both of which contribute to conditions favorable for creating non-strategic technical debt. And the kinds of technical debt produced by this mechanism, or any mechanism associated with schedule or budget pressure, tend to be subtle — they’re the types least likely to become evident in the short term. For example, technical debt that might make a particular kind of enhancement more difficult in the next project is more likely to appear than technical debt in the form of a copy of some code that should have been replaced by a utility routine. Copies of code are more easily discovered and more likely to be retired in the short term, if not in the current project. Awkward architecture might be more difficult to identify, and is therefore more likely to survive in the intermediate or long term.

In other words, the forms of technical debt most likely to be generated are those that are the most benign in the short term, and which are therefore more likely to escape notice. If noticed, they’re more likely to be forgotten unless carefully documented, an action that’s unlikely to be taken under conditions of schedule and budget pressure. In this way, the non-strategic technical debt created as a result of unrealistic optimism is more likely than most technical debt to eventually become legacy technical debt.

Policymakers can assist in addressing the consequences of unrealistic optimism by advocating for education about it. They can also advocate for changes in incentive structures and performance management systems to include organizational standards with respect to realism in promised benefits, costs, and schedules.

References

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

Available: here; Retrieved February 26, 2017.

Cited in:

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Available: here Retrieved: March 16, 2017

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

Order from Amazon

Cited in:

[Beardsell 2010] Julie Beardsell. “IT Backsourcing: is it the solution to innovation?”, SMC Working Paper Series, Issue: 02/2010, Swiss Management Center University, 2010.

Available: here; Retrieved: February 15, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Delen 2007] Guus Delen. “Decision and Control Factors for IT-sourcing,” in Handbook of Network and System Administration, Jan Bergstra and Mark Burgess, eds., Boston: Elsevier, 929-946 (2007).

Order from Amazon

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

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:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Hamburger 1973] H. Hamburger. “N-person Prisoner’s Dilemma,” Journal of Mathematical Sociology, 3, 27–48 (1973). doi:10.1080/0022250X.1973.9989822

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kahneman 1977] Daniel Kahneman and Amos Tversky. “Intuitive Prediction: Biases and Corrective Procedures,” Technical Report PTR-1042-7746, Defense Advanced Research Projects Agency, June 1977.

Available: here; Retrieved: September 19, 2017

Cited in:

[Kahneman 1979] Daniel Kahneman and Amos Tversky, “Intuitive Prediction: Biases and Corrective Procedures,” Management Science 12, 313-327 (1979).

Cited in:

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

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Kinkel 2016] Steffen Kinkel, Angela Jäger, Djerdj Horvath, and Bernhard Rieder. “The effects of in-house manufacturing and outsourcing on companies’ profits and productivity,” 23rd International Annual EurOMA Conference, At Trondheim, Volume: 23, June 2016.

Cited in:

[Kusnet 2007] David Kusnet. “Highway Robbery II,” report of the National Association of State Highway and Transportation Unions (NASHTU).

Cited in:

[Laplante 2007] Phillip A. Laplante. What Every Engineer Should Know About Software Engineering. New York: CRC Press, 2007.

Order from Amazon

Cited in:

[Li 2015] Z. Li, P. Avgeriou, and P. Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Lowy 2004] A. Lowy and P. 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:

[MacFee 1987] John MacFee. “Atchafalaya,” The New Yorker, February 23, 1987.

Available: here; Retrieved: February 5, 2018.

Cited in:

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

Available: here; Retrieved November 11, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[Ostrom 1990] Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Ostrom, Elinor. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Pronin 2002] Emily Pronin, Daniel Y. Lin, and Lee Ross. “The bias blind spot: Perceptions of bias in self versus others.” Personality and Social Psychology Bulletin 28.3 (2002): 369-381.

Available: here; Retrieved: July 10, 2017

Cited in:

[Willcocks 2004] L. Willcocks, J. Hindle, D. Feeny, and M. Lacity. “IT and Business Process Outsourcing: The Knowledge Potential,” Information Systems Management 21(3), (2004), 7-15.

Cited in:

Other posts in this thread