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, 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.
Accepted classification frameworks are technologyoriented
Within enterprises of significant size, classifying technical debt is an essential step in designing programs for reducing the cost of carrying technical debt. Although the choice of classification scheme depends on one’s objectives, most classification schemes explored so far in the technical debt literature are more suitable for use by technologists than by policymakers. But, unsurprisingly, the assistance they provide to policymakers relates mostly to policies that affect technologist behavior or resource allocation across technical activities.
An example might clarify the issue. Technologists tend to create classifications of technical debt that emphasize designer and implementor intentions. For example, Fowler has created a widely accepted two-dimensional [Lowy 2004] classification [Fowler 2009] that characterizes technical debt according to the Degree of Wisdom in incurring it (he calls this dimension Reckless/Prudent), and Degree of Intentionality in incurring it (he calls this dimension Deliberate/Inadvertent). See “Technical debt in software engineering” for more.
In the technical literature, this classification, and another due to McConnell [McConnell-slides 2013] are widely but not universally accepted. For example, some believe that no artifact is technical debt unless its presence (or absence) was the result of a conscious decision [Adobe Blogs 2014]. Some adherents of this view would reject all of Fowler’s “Inadvertent” technical debt.
This focus on engineering intention likely arises, in part, for two reasons. First, technologists tend to have good access to their own intentions, and to the intentions of other technologists. The second reason relates to developing plans for retiring particular classes of technical debt. Knowledge of the intentions of the people who created (or omitted) the artifacts in question is helpful in planning debt retirement projects..
Policymakers need a more inclusive classification framework
For policymakers, while both of these widely accepted classifications are helpful, they are inadequate. Intentionality with respect to technical debt formation is indeed a valuable consideration in developing technical debt policy. But technical debt can arise for reasons unrelated to engineers’ intentions. Indeed, it can arise for reasons unrelated to any enterprise activity. For these reasons intention-based classifications provide inadequate guidance for policy formation.
Consider technological advancement that arises from sources external to the enterprise. For example, with the emergence of the HTML5 standard, many Web sites became obsolete. They didn’t exploit capabilities that had become available. These sites were in need of updating to remain competitive in their markets. The new standard also created a ned to replace capabilities that emulated the new standard, but which exploited alternative technologies. All of these artifacts—including those that existed, and those that didn’t, comprise technical debt.
Relative to technical debt management, an enterprise that devotes resources to monitoring external technology trends would have an advantage over competitors that tend to focus solely on employee behavior.
Last words
Technological advancement that occurs outside the enterprise can thus create technical debt within the enterprise. This is just one example of spontaneous generation of technical debt. Thinking about technical debt this way, you can probably identify other sources of spontaneous generation. Together, they create a need for policies that can address their management.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
Because effective technical debt management requires cooperation from almost everyone, an enterprise-wide definition of technical debt is essential. Absent a shared definition of technical debt, controversy can develop. Controversy is especially likely among those who have previously encountered the concept—namely, among technologists. Policymakers can make invaluable contributions to the design of the cultural transformation that will enable control of technical debt.
A physical expression of shared commitment. Effective technical debt management requires both a shared understanding of what it is and a shared commitment to do what’s required to control it.
Li et al. [Li 2015] found that defining what is and what isn’t technical debt remains an open question in software engineering. Even if we restrict the discussion to software constructed in-house, opinions about what constitutes technical debt do differ. The authors found that in the literature of technical debt, “The term ‘debt’ has been used in different ways by different people, which leads to ambiguous interpretation of the term.”
This finding is perhaps the most significant for policymakers. It suggests that controlling technical debt might require forging an organizational consensus about the meaning of the term technical debt. The people of most organizations come from many different backgrounds. Those with little knowledge of technical debt have few preconceptions. But those who are aware of the issue probably interpret the term technical debt in a variety of ways. Because some of those who do have awareness of the term are likely to have strong opinions about its meaning, one can anticipate a need to resolve these differences.
The effect of an absence of standards
Some technical terms, like RAID, byte, compiler, and kilowatt, have widely accepted standard definitions. Although the term technical debt has found wide use, it has no standard definition. What some people categorize as technical debt, others do not. Those who are accustomed to working with terms that have precise, widely accepted definitions might tend to assume that the term technical debt does have (or should have) one as well. This assumption can create some difficulty for people who don’t realize that others might have differing views of the definition of the term.
For example, there are those who believe that defects are not technical debt. And some believe that no element of a technological asset can constitute technical debt unless it is part of a product that a customer uses. Our definition differs with both of these views.
Last words
Policymakers must be aware that there is a lack of consensus about the definition of technical debt. Our definition, crafted specially for the use of policymakers, might seem unusually broad to technologists and engineers. For that reason alone, it’s advisable to become familiar with the various ways technologists use the term. Understanding their perspective is essential to formulating sound policy deserving of their respect.
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
Surface tension holds raindrops together on a grapevine. We often think of tension as a negative, destructive force. But tension—in the case of raindrops, surface tension—is what holds a raindrop together. Tension gives the raindrop structure and integrity. The tension between technologists and policymakers can also be constructive. It can ensure that the enterprise manages technical debt in ways that balance the political imperatives of technology and strategic health.
Tension between policymakers and technologists, which can manifest as misalignment of their respective priorities, is a significant contributor to uncontrolled growth of technical debt. In this thread, I explore sources of this tension. That exploration introduces concepts that can assist policymakers and technologists in their efforts to control technical debt growth.
Technical debt is not just a technical problem
The objective of technical debt management policy is effective, sustainable control of technical debt. In an enterprise that has achieved this objective, technical debt serves as a strategic tool. That tool assists in attaining and maintaining market leadership. In such an organization, technical debt does exist, and some legacy technical debt might remain in place. But the enterprise manages technical debt growth strategically, if growth occurs at all. The enterprise addresses any technical debt that carries significant MICs. And it pays special attention to technical debt that compromises productivity and enterprise agility. In short, the enterprise addresses technical debt not only as a technological issue, but also as a component of business strategy.
This stance is at odds with the historical position most enterprises have adopted vis-à-vis technical debt. In the historic view, technical debt is a technical problem, if it is recognized at all. Most enterprises relegate technical debt management to the technologists. Frequently, then, technologists view as interlopers any policymakers who enter the discussion about technical debt. Any such policymakers usually arrive late to the discussion. Technologists often view them as less-than-knowledgeable invaders attempting to seize control of a piece of the technologists’ domain. In this way tensions can arise between policymakers and technologists. Such tensions complicate the problem of managing technical debt.
Sources of tension
One possible source of this tension is apparent in a study of the literature of technical debt, which is evolving so rapidly that it has itself become a focus for research. Li et al. [Li 2015] have produced a review of the software engineering technical debt literature. From this review we can extract insights useful to policymakers. They studied only the literature relating to technical debt in software engineering. But their conclusions are, at least in part, applicable to any field in which the components of the finished product are executed within software tools before being committed to operational form. This covers a wide array of knowledge-intensive endeavors, including mechanical system design, electronic design, framing of legislation, process design, architecture, and even book authorship.
Last words
In this thread, I explore the sources of the tension between the modern reality of technical debt as an enterprise issue, and the historical situation of technical debt as a technological issue. This can serve as a guide for policymakers in reframing technical debt. The archaic view of technical debt is as a technological issue dependent for resolution on enterprise resources. The modern view is as an enterprise issue dependent for resolution on technological resources.
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
Elizabeth Holmes backstage at TechCrunch Disrupt San Francisco 2014. She was 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 technology enabling blood testing with small amounts of blood. Theranos’s process supposedly required only 0.1% to 1% of the amount of blood conventional technologies require. 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.
Although creating and deploying policies to manage technical debt is necessary, it isn’t always sufficient for achieving control. Even if training and communication programs are effective, intentional circumvention of technical debt management policy remains possible. Malfeasance can lead to 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 incur technical debt or extend the lifetime of existing technical debt.
Examples of how malfeasance can lead to technical debt
Consider an example from software engineering. To save time, an engineer might intentionally choose a deprecated approach. When the malfeasance comes to light, a question naturally arises. Specifically, in what other places has this individual (or other individuals) been making such choices? In a conventional approach to controlling this form of technical debt, we might examine only the engineer’s current work. But a more comprehensive investigation might uncover a trail of malfeasance 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. It 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 some decisions to defer maintenance on complex systems are arguably negligent.
History provides many clear examples of how malfeasance can lead to new technical debt indirectly. Consider the Brooklyn Bridge. Many of the suspension cables of the bridge contain substandard steel wire, which an unscrupulous manufacturer provided to the bridge constructors. When the bridge engineer discovered the malfeasance, he recognized that he couldn’t remove the faulty wire that had already been installed. So he compensated for the faulty wire by adding additional strands to the affected cables. For more, see “Nontechnical precursors of nonstrategic 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 can have dire consequences. It 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.
Why malfeasance deserves special attention
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 do not possess. Once they’re on board, they expose the enterprise to the risk of technical debt creation through substandard work. That work 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 factor to technical debt formation when the beneficiary of a proposal is the decision maker. An alternative beneficiary, just as harmful, is the advocate who takes credit for the short term effects of the decision. In either case, the beneficiary 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 necessary attributes of technical debt management programs that deal effectively with malfeasance.
Corrective measures
The organization can undertake corrective measures in a straightforward manner when inadvertent policy violations occur. For example, a technical debt retirement program might encounter unexpected difficulties in setting priorities when individual performance metrics conflict with the technical debt control program. Such conflicts can be inadvertent and collaborative resolution is feasible, if challenging.
But with regard to malfeasance, difficulties arise when policy violations come to light. When the violations are intentional, corrective action usually entails investigation of the means by which the infraction was achieved, and how it was concealed. When these activities involve many individuals attached to multiple business units, we need some means of allocating the cost of corrective action. 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, only investigation can determine whether a pattern of violations exists. Technical debt forensic activities require resources. They need 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 technical debt management policies. Most important, it includes the certainty of discovery of intentional infractions. These factors require commitment and continuing investment.
Policy frameworks are at risk of decreased 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. Worse, perpetrators often try to mislead investigators and managers about the debt’s 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.
[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.
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
Cultural debt can be expensive. Like technical debt, it can incur ongoing metaphorical interest charges (MICs). Schein defines organizational culture as “…a pattern of shared basic assumptions learned by a group as it solved its problems of external adaptation and internal integration…” [Schein 2016]. Following the concept of technical debt, we can regard as cultural debt the subset of shared basic assumptions comprising enterprise culture that are no longer fitting for enterprise realities. We can also include as cultural debt any assumptions that ought to be shared, but which are missing or are only partially shared. And we can include shared assumptions that conflict with each other and need to be resolved.
An example of cultural debt: the term “IT”
A tape measure calibrated in both feet/inches and meters/centimeters. We can regard the need to possess tools that serve both measurement systems as the metaphorical interest charges on a technical debt. The debt is the result of failing to retire the older “English” system. But from another perspective, the debt involved is actually cultural. Retiring the older system would truly involve a cultural shift.For most modern enterprises, an element of cultural debt is the very term IT—information technology. Coined in 1958 by Leavitt and Whisler [Leavitt 1958], the term was then appropriate. It was apt up to about 20 years ago. Until then, the role of IT was primarily management, storage, retrieval, manipulation, and presentation of information. Although those functions remain relevant, the responsibilities of IT have expanded dramatically since then. In many organizations, IT is now responsible for designing, implementing, and maintaining the communication infrastructure. That infrastructure includes Internet access, personal computers, networking, Web presence, telephones, video conferencing equipment, and television.
The modern role of communication
Communication plays a critical and strategic role. An essential element for success is a clear understanding of what IT does and what it contributes. Regarding IT as the “information technology” function of the enterprise therefore risks overlooking and undervaluing these more recently acquired responsibilities. And since the IT function is no longer solely responsible for enterprise information, using the name “IT” or the term information technology risks overvaluing the role of the IT organization relative to information management, while undervaluing its role relative to communications.
In Schein’s culture framework, the term IT reflects a shared assumption about IT’s role. That assumption is that IT is responsible for information. Unfortunately, that assumption is no longer well aligned to the reality of IT’s role. We can regard this misalignment as a cultural debt.
The consequences of cultural debt
The consequences of this particular kind of cultural debt can be severe. For instance, IT is typically responsible for selecting and configuring software for personal computers (PCs). This responsibility can arise as a consequence of two shared assumptions. First is the assumption that computers process information, and second, that IT is responsible for technology-based information processing. The result is that the person who uses the computer doesn’t make all decisions about what many regard as a “personal” computers. When the IT decision differs from the personal preferences of the computer user, we can find conflict.
Worse, a centralized decision process for determining PC configurations is likely to produce outcomes less suitable than would a process more focused at the individual level. That adds to the frustrations of PC users, and exacerbates the conflict between them and IT. To mitigate the risk that some PC users might circumvent IT policy, IT must take steps to prevent such actions. We can regard all of that activity, on the part of both IT and the PC users, as metaphorical interest charges on cultural debt.
An example of retiring cultural debt
In 1987, Edward Yourdon founded a magazine then known as American Programmer. In 1990, Cutter Information Corporation purchased the rights to American Programmer and created Cutter IT Journal. That name includes the term IT. At the time, IT was more suitable than the term programmer. As noted above, the term IT, while once useful and apt, is now outmoded at best and often misleading. Just as the functional name IT in organizations constitutes cultural debt, so it does in the name of a journal.
So in the autumn of 2016, Cutter IT Journal retired the cultural debt in its name, and became Cutter Business Technology Journal. Journals rarely change their names. When they do, the impact of the journal is temporarily depressed. The reduction in impact is due to the split of citations between the former title and the new title. That effect lasts for about two years or so [Tempest 2005]. But as research fields change, their journals must keep pace. Evidently Cutter felt a significant need to retire its cultural debt—significant enough to justify a temporary reduction in impact.
What about cultural debt retirement in companies?
Difficulties associated with retiring cultural debt depend strongly on both the nature of the culture and the nature of the debt. To provide insight into these issues, let’s continue with our exploration of the term IT and its cultural implications.
In many organizations, IT reports to a Chief Information Officer (CIO). Associated with this official’s title are some of the same cultural debts we find for the name “IT”. First, CIOs aren’t the only officers with information management responsibility. Second, many CIOs have responsibilities that transcend information management. Their responsibilities include, for example, the communication infrastructure. Unlike other peer titles such as CEO, CFO, CMO, and COO, the CIO title evokes separation from business-oriented decisions. That separation contributes to a cultural wall between “IT” and “the business.”
The view of IT as an information-centric service organization is perhaps a remnant of the 20th century. Cultures that have this view can become problematic for the organization. The problem is that they tend to regard IT as a source of expense to be minimized, rather than as a strategic partner [Ross 2000]. Still, trends toward strategic acceptance of IT are favorable, according to recent surveys of CIOs [CIO 2018].
The reality is that business technology must contribute to formulation and implementation of enterprise strategy. But some CIOs and their organizations are viewed as separate from “the business.” This limits their ability to help shape enterprise strategy. But it also subjects them to cultural assumptions about their responsibilities that in some instances conflict with each other. That’s a significant source of the metaphorical interest charges on the cultural debt.
One way out of this cultural debt
One possible way to retire this debt might entail retitling Chief Information Officer to Chief Business Technology Officer (CBTO). That’s precisely what happened at Forrester Research in 2011 [Plant 2014].
Unfortunately, the name CBTO conflicts with the three-word pattern of enterprise officer titles (C*O), which might create an urge to name the office Chief Technology Officer (CTO). But that role usually has responsibility for the functions that create technological products or services. Thus, for many organizations, to create a CBTO where there is already a CTO might create further sources of conflict. Using the CTO designation for the CBTO is probably impractical.
But we must find some way to retire this particular cultural debt, because it’s such an effective generator of technical debt. CBTO seems to be the best available path.
References
[Adobe Blogs 2014] Adobe Blogs. “What is Technical Debt?,” Adobe Blogs, September 8, 2014.
[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.
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.
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 United States, the Broken Windows theory of crime control first appeared in the public conversation in 1982. Kelling and Wilson described it in The Atlantic (then known as The Atlantic Monthly) [Kelling 1982]. Briefly, the theory suggests that in urban environments, we can prevent serious crime by taking some simple steps. They include applying police resources to preventing small crimes such as vandalism, public drinking, and toll jumping. These measures create an atmosphere of order and lawfulness. Gladwell popularized the idea in his explosive best seller The Tipping Point [Gladwell 2000].
In the year before Gladwell’s work appeared, Hunt and Thomas incorporated the Broken Windows theory into their work, The Pragmatic Programmer. They suggest 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 additional technical debt. Within the software community, the Broken Windows theory of managing technical debt is widely accepted [Note a].
Skepticism about the Broken Windows Theory
However, between Kelling’s work in 1982 and the work of Hunt and Thomas in 1999, something happened in criminology. 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].
Meanwhile, O’Brien, Sampson, and Winship, analyzing “big data,” failed to produce strong evidence of the theory’s validity. They did find a weak positive correlation between social orderliness and lawful behavior [O’Brien 2015]. But their research also showed a strong positive correlation between private violent behavior and major crimes. Others noted that what appeared to be positive results for the application of Broken Windows 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. The Center 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. (See their review of Broken Windows Policing.)
The software engineering community is less skeptical
But even as doubts developed about the efficacy of Broken Windows policing for crime prevention, Broken Windows continued to find adherents in the software community. Software researchers continued to regard the theory as pertinent to managing technical debt in software. 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 better ways of understanding the phenomena in question.
Last words
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.
[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.
[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.
[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.
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.
[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.
[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.
[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.
[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.
[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.
A map of the Boston Common and Public Garden, circa 1890. By 1890 it was basically a park. But as late as 1830 it was still in use as a cow pasture. Home refrigeration was rare then, except by ice blocks. 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. 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
Many believe that technical debt arises, in part, because of a phenomenon known as the Tragedy of the Commons [Hardin 1968]. The Tragedy of the Commons is an allegory that purports to demonstrate how shared resources degrade. It holds 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. 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.
How adherents of the theory manage shared assets
The resources in question here are the assets that tend to accumulate technical debt. Adherents of the theory would impose order by dividing each technological asset into one or more sectors, sometimes called development silos. Each development silo would have one organizational unit designated as the “owner.” Owners have the power to develop, maintain, or extend that sector [Bossavit 2013] [Morris 2012]. They would presumably resolve irreconcilable disagreements about the direction or purpose of a particular sector 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. Costs increase because of reduced sharing and increased need for testing. We can regard such an approach as dysfunctional conflict avoidance [Brenner 2016b].
How adherents apply the theory to explain technical debt
At one time researchers in political economics regarded the Tragedy of the Commons as universally valid. But subsequent research has demonstrated that the principle it describes isn’t 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 the logic of the situation compels each herdsman to exploit the shared resource to the maximum. Each herdsman puts his or her own interests ahead of the welfare of the resource.
But the theory doesn’t work
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 immediate need justifies the expenditure. 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 organization abandons the shared asset because it becomes unmaintainable.
However, careful research shows that Hardin’s Commons allegory isn’t 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.
Enter Elinor Ostrom
Certainly there are many examples of shared resources degrading along the lines Hardin suggests. An example is 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 sustainably [Ostrom 2009] [Ostrom 1990]. Ostrom 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 resources open to unregulated use. A World Bank Discussion Paper by Bromley and Cernea [Bromley 1989] clearly describes the misapplication of the Tragedy of the Commons:
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 capacity for aiding our understanding of resource management regimes falls far short of its power as a metaphor. 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]. Lloyd had observed this much earlier [Lloyd 1833].
The real tragedy of the Tragedy of the Commons
The real tragedy for technology managers would be their failure to learn from the past errors of social scientists and political economists. If they then repeat this now well-understood confusion about the domain of applicability of Hardin’s allegory, they would be compounding the tragedy.
We can apply Ostrom’s result to the problem of managing technical debt if we identify the technical asset as the shared resource. Next we would 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. If the community devises rules, customs, and sanctions that manage the technical debt, the resource is sustainable. 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.
Last words
The Tragedy of the Commons is a distraction. 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 if the community sharing the asset devises customs, rules, and sanctions that control technical debt. You just can’t have a free-for-all unregulated regime, as most organizations now do. Management and practitioners must collaborate to manage the asset. And regular updating of the customs, rules, and sanctions 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.
[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.
[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.
[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.
[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.
[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.
[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.
[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
[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.”
[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.
[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.
[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.
[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.
[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.
[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.
The aftermath of the 2004 Indian Ocean earthquake and tsunami, 26 December 2004. Shown is what remained of Meulaboh, Sumatra, Indonesia, after the tsunami struck. 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 (LHD-6), 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.
During policy debates, some advocates take positions that offer short-term advantages in exchange for long-term disadvantages. The long-term disadvantages are often in the form of new technical debt. Or they might advocate allowing legacy technical debt to remain in place. Some of these decisions can be strategic, and they can benefit the enterprise. But when the primary beneficiary of the strategy is the decision maker or the advocate, a dominant contributing factor can be organizational psychopathy. This risk is higher 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.
Such decisions can be counterproductive for the enterprise in the long term. But decision makers or advocates nevertheless favor these decisions, because they plan to take credit for the short-term benefits. They then move on to new career positions elsewhere to escape the technical debt problems they created. In effect, the decision maker or advocate plans to “surf the debt tsunami.”
The organizational psychopath
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. They can be exceedingly charming, intelligent, charismatic, and adept at deception. They’re 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.
Last words
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.
[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.
[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.
[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.
[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.
[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.
[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.
[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
[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.”
[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.
[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.
[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.
[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.
[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.
[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.
When the owner of an asset, especially a software asset, contracts to provide a capability to a customer incorporating a use of that asset, contract restrictions can lead to technical debt. 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. But complications can arise unless the contractor can perform the work in a manner compatible with any pre-existing or anticipated future other uses of the asset. Even so, some contract restrictions can cause the owner of the asset to incur technical debt.
How technical debt can enter the picture
A power adaptor/converter for international travelers with U.S. standard equipment. This device provides conversion for both hardware connection and voltage supplied. We can regard the wide variation in electric power standards worldwide as a technical debt. Someday, in the probably distant future, a world standard will emerge and we will retire that debt. Until then, adaptors like these are travel necessities.Some contracts restrict such work. For example, a government customer might require ownership of the work performed. 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 the government customer can then own, or which can be classified as secret if necessary. These moves insulate the original asset from these ownership restrictions.
The result is tolerable after completion of one such contract. But over time, as their number increases, the adaptors become a form of technical debt. The asset owner must maintain each adaptor 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, cloning replicates both the asset and any technical debt it carries. And correcting defects in the asset requires correcting that same defect in any clones that carry it.
The general forms of the problem
The problem is more general than suggested above. It also appears in the case of software that supports multiple platforms, or which is available in multiple versions supporting 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. They must then perform that update, including all testing and documentation, 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 that clone differs from other clones. If they discover a new defect, 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 implementing it in some clones might require a unique approach. Life can get very complicated.
Organizations entering into contracts of this kind would be wise to include language limiting their obligations to maintain the original asset against any changes. Or they might include an explicit statement of the parties’ intentions relative to financial support for any continuing obligations to maintain that asset.
Last words
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. And that 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.
[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.
[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.
[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.
[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.
[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.
[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.
[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
[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.”
[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.
[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.
[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.
[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.
[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.
[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.
Some projects undergo budget depletion exercises after budget cuts. Or the exercises might occur when there’s evidence that the funds remaining won’t cover the work remaining. Formats vary, but the typical goal of these exercises is downscoping. We remove, relax, defer, or suspend some requirements. With limited funds, we execute downscoping in a manner that leads to technical debt.
A physical example
Photo courtesy USACEThe accompanying photo shows the Old River Control Complex on the Mississippi River. The US Army Corps of Engineers (USACE) built it and operates it. It controls the flow from the Mississippi into the Atchafalaya River, a distributary. The Mississippi would otherwise have rerouted itself into the Atchafalaya, which has a steeper gradient to the ocean. Since that would have deprived New Orleans and its industrial facilities of water and navigational channels, USACE maintains flow control facilities.
The industrial facilities of the lower Mississippi constitute a technical debt. Their existence is no longer compatible with the “update” Nature is trying to deploy. But our national budget won’t support repositioning New Orleans and its industrial facilities. So we redirect the flow of water from Nature’s course to one more compatible with the industrial base. The Old River Control Complex, with levees, dredging projects, and gates throughout lower Louisiana, are the MICs we pay for the technical debt that is the outdated position of New Orleans and its industrial base. For more about Atchafalaya, see the famous New Yorker article by John McPhee [MacFee 1987].
A broad array of effects
Here’s an illustrative scenario. At the time downscoping begins, the work product might contain incomplete implementations of items that are due for removal from the list of objectives. This removal renders unnecessary a set of accommodations contained in surviving artifacts. They comprise a most insidious type of debt that’s difficult to detect. It’s difficult to detect because the affected system components appear to be merely overly complicated. Recognizing them as a residual of a cancelled capability requires knowledge of their history. Unless we document these artifacts 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 serve a purpose, 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. The enterprise might then lose track of them when team members move on to other work.
Sometimes, budget depletion takes effect even before the work begins. This happens, for example, when project champions unwittingly underestimate costs to gain approval for the work they have in mind. The unreasonableness of the budget becomes clear soon after the budget approval, and its effects 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.
Last words
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.
[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.
[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.
[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.
[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.
[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.
[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.
[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Lowy 2004] Alex Lowy and Phil Hood. The Power of the 2x2 Matrix: Using 2x2 Thinking to Solve Business Problems and Make Better Decisions. Jossey-Bass, 2004.
[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.”
[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.
[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.
[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.
[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.
[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.
[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.
