The dilemma: outsource technical debt retirement, or do the work in-house?
From time to time, people ask me about the wisdom of outsourcing technical debt retirement projects. Because the answer depends so strongly on the particulars of the situation, there’s no general answer. But there are general guidelines—factors to consider when making the decision. Let’s refine the question first, in the form of a case:
Our organization uses an array of software and hardware assets to execute our mission. We developed some of these systems so long ago that the original developers have departed. They left here for other companies, or they left in spinoffs, or they moved on to other parts of our company. Some of these moves were due to reorganizations, some to promotions, and some to personal career decisions.
Most of the people who are now maintaining these assets have learned by doing. This has been necessary because we haven’t kept the documentation current enough to be a reliable reference. We know that the systems harbor significant levels of technical debt, and the documentation itself carries debt. So we want to retire all that debt, but it’s a big job. Should we hire contractors? Or a vendor who specializes in large scale technical debt retirement projects?
This is a typical situation, but many variables are unspecified. And typically, even more variables are unknown. Those unspecified or unknown variables make the decision tricky. To illustrate, I’ve listed below seven issues that would affect decisions about outsourcing technical debt retirement projects.
In-house staff probably has useful knowledge
If the in-house staff has much undocumented information about the current configuration of the assets, they have an enormous advantage over contractors or an outside vendor trying to do the same work. And even though the in-house staff wasn’t involved in initial development, they probably have valuable knowledge of the asset if they’ve been engaged in maintenance or enhancement to any significant degree. And they probably know more about the assets than any outsider would. So if the ultimate decision is to outsource the work, try to devise an arrangement in which the most knowledgeable in-house staff are acting in a reference role.
Outsourcing technical retirement effectiveness depends on knowledge of enterprise strategy
Knowledge of enterprise strategy is useful in technical debt retirement projects. For example, suppose we know that a future project will be rendering some or all of a given asset irrelevant. We can use that knowledge to focus the debt retirement effort.
However, in some cases, revealing strategy to outside vendors is risky, even with ironclad NDAs in place. So some asset owners avoid revealing strategy information. They accept that the outside vendor might perform otherwise-wasteful tasks. This approach can be a low-cost way to manage the risks that arise from revealing strategy. Others choose to perform the work in-house. Working in-house enables them to use their knowledge of strategic direction when allocating effort in debt retirement or when deciding what the transformed asset should look like.
Detailed knowledge of the debt retirement effort is itself valuable
Knowledge of the what and why of the actual debt retirement work can be helpful in resolving any difficulties that surface after completion. That knowledge is also helpful in future work on similar assets.
With outsourcing, after the work is done, any unreported information about what the vendor did and why they did it departs with them. If in-house staff perform the work, that information remains in-house. This can be very helpful if the asset is a critical asset, or if you expect further future enhancement work or debt retirement work on that asset or similar assets.
Debt retirement work almost inevitably generates new knowledge
When people work on debt retirement, they usually have specific objectives. Even so, as they work, they generally uncover issues they hadn’t anticipated. Both in-house staff and contractors experience these aha’s. The difference between them is what happens after the work is done.
If in-house staff does the work, they can use this newfound knowledge in other projects, including new development. Not necessarily so with the outside vendor. If the same vendor is employed again for another effort, they can apply that knowledge if doing so is in scope for the next contract. But if that vendor doesn’t return, or the scope of subsequent efforts doesn’t permit it, then they can’t apply that knowledge. Moreover, the vendor might not even report what they found, though most would because they hope it will lead to more work. If they do report it, the in-house contract monitor should be sophisticated enough to recognize how valuable that kind of information is. Sadly, many are not.
Asset service disruptions can be problematic
Another difficulty with outsourcing technical debt retirement projects relates to asset service disruptions. In some debt retirement efforts, some assets must be taken out of service for periods that are moderately disruptive or worse. In-house staff likely have relationships of long standing that make cooperation, negotiation, and consideration relatively easy.
If negotiation difficulties arise, the lowest level executive or manager who’s responsible for all parties can facilitate resolution. And over time, with practice, all parties learn to work out these issues more effectively. With outside vendors, this process can be more difficult, because of the absence of existing relationships, the termination of relationships when vendors exit the scene, and the lack of formal authority of some specific executive or manager.
If in-house staff can’t do the work, consider hiring
If the in-house staff is overloaded, or if they lack the skills necessary to take on the technical debt retirement effort, outsourcing can seem like the only workable approach. Not so fast though. If a stream of debt retirement projects is in your future, consider the advantages of building a debt retirement function with a long-term agenda. Examine again the factors cited above to determine the scale of the advantages of building such a team.
Outsourcing probably works well for refactoring
The one activity for which outsourcing can be a big win is refactoring. Refactoring doesn’t usually require much knowledge of company strategy. And it doesn’t require much “nonlocalizable” knowledge. That is, the requirement that the refactoring not cause changes in asset behavior enables the asset owner to write a very tight contract with the debt retirement team. They can then perform their work with confidence because they can test the asset’s behavior incrementally. Also, with refactoring, asset service disruptions are usually minimal.
Last words
One last suggestion. With outsourcing, the vendor might have significantly more experience with technical debt retirement efforts than does the client. This asymmetry gives the vendor an advantage at every stage. For technical debt retirement efforts, they know more about contracting, devising statements of work, defining acceptance criteria, and managing risk. Most important, they have experience dealing with the many speed bumps that can occur in these projects. To manage the risks of that advantage, consider retaining a consultant experienced in these situations. This person’s role is to monitor communications between enterprise and vendor to ensure fairness. The mere presence of such an individual can deter the vendor from some of the abuses that can be so tempting in these asymmetric situations when trouble arises.
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.
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.
[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.
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.
[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.
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
[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.
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
[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.
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
[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.
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
[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.
Most of the nontechnical 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 that cover outsourced work. As described in “Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma,” Boehm, et al., call this the “Conspiracy of Optimism.” [Boehm 2016] But outsourcing engineering work can introduce pathways for incurring technical debt that are specific to outsourcing.
The risks of incurring technical debt from outsourcing
Green fields. Greenfield outsourcing, also known as startup outsourcing, is the outsourcing of activity that the enterprise has never performed in-house. Greenfield outsourcing is especially tricky with respect to technical debt formation. The risk arises because much of the expertise necessary to perform the work in question is probably not resident within the enterprise. That void in enterprise expertise makes for difficulties in managing technical debt in the outsourced artifacts.Outsourcing is inherently more likely to incur technical debt than is equivalent work performed in-house. 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 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 technical debt in deliverables potentially remain hidden during the lifetime of the outsource contract, years might pass before the issue becomes evident. That inevitably complicates the task of understanding the root cause of the problem.
Six ways outsourcing can contribute to technical debt
In what follows, I use the term vendor to denote the organization performing the outsourced work. I use 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, and which has remained in-house.
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 exhaustive. Quite possibly other phenomena also contribute to technical debt formation in the context of outsourcing.
Progressive erosion of retained organization capabilities
Over time, after outsourcing work on a particular asset, the enterprise can expect erosion of some engineering expertise. The expertise most vulnerable is that needed to manage, evaluate, understand, or, if need be, to re-insource (or backsource) the outsourced work [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 outsourcing decisions. That reallocation is part of the economic justification of outsourcing decisions.
But even if the enterprise continues to employ the people who formerly performed the outsourced work, the deleterious effects remain. Those employees, filling new roles, likely become less familiar with the current work and therefore less able to perform it. And since they’re now carrying out other assignments, their availability is limited. In the public sector, the organizations that perform the outsourced work exacerbate this phenomenon by recruiting staff from their former agencies [Kusnet 2007]. In manufacturing, Kinkel, et al., suggest that, paraphrasing, outsourcing disturbs the formation of internal competence [Kinkel 2016].
Thus, outsourcing engineering efforts can erode the ability of the enterprise to perform the outsourced work internally. Likewise, it erodes enterprise capability to monitor or evaluate the work when vendors perform it. Consequently, the enterprise is less able to monitor, evaluate, or retire any technical debt that accumulates in the outsourced work products.
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 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
Technical debt formation is possible even if there is only one vendor. 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 needs, and might develop duplicative tools independently. As a second example, consider 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 manages communications through multiple contacts, stovepiping is more likely. New technical debt is more likely to form.
Loss of continuity in the outsourced engineering staff
Unless the agreement between the vendor and the enterprise specifically addresses staff volatility, an additional risk arises. Staff turnover or reassignment within the vendor organization can lead to technical debt. This can happen in just the same way that turnover in-house can lead to technical debt. But the risk is most significant at interfaces between one version of the product or service and the next. With outsourcing, however, the vendor has little internalized motivation to control this phenomenon. Moreover, 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 technical debt formation. This happens because engineers create and deploy artifacts that they must revisit later. The need for rework arises after engineers learn of business plans they didn’t know about 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, the enterprise has never before performed work like the outsourced work [Delen 2007]. This kind of outsourcing is startup outsourcing or greenfield outsourcing. In these cases, typically, the enterprise must 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 aren’t enterprise employees. Hiring and retaining people for these roles can be difficult. Startup challenges arise 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.
Last words
A policy that would address these risks is one that would facilitate accomplishing three objectives:
Retain organizational capability sufficient to assess the effect on technical debt of any outsourced engineering work
Represent the effect on technical debt faithfully in any financial models used in making the outsourcing decision
Include in financial models the effects of technical debt, the cost of carrying technical debt, and the effects on controlling technical debt when deciding whether to extend outsourcing contracts with vendors.
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.
[Beardsell 2010] Julie Beardsell. “IT Backsourcing: is it the solution to innovation?”, SMC Working Paper Series, Issue: 02/2010, Swiss Management Center University, 2010.
[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.
[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.
[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
[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.
[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.
[Willcocks 2004] L. Willcocks, J. Hindle, D. Feeny, and M. Lacity. “IT and Business Process Outsourcing: The Knowledge Potential,” Information Systems Management 21:3, 7-15, 2004.
Confirmation bias is a cognitive bias [Kahneman 2011]. It’s the human tendency to favor and seek only information that confirms our preconceptions. It also causes us to avoid information that disconfirms our preconceptions. For example, the homogeneity of cable news channel audiences is a result of confirmation bias. Another result is the alignment between preconceptions of the audience and the slant of the newscast for that channel.
How confirmation bias can lead to technical debt
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 due to what is now called the “metric mix-up.” The Lockheed Martin team that constructed and programmed the MCO used Imperial units. But the team at JPL that was responsible for flying the MCO used metric units. After the loss of the MCO, an investigation led by NASA uncovered the mix-up. One of the many changes resulting from this loss was increased use of reviews and inspections. We don’t know why reviews and inspections weren’t as thorough before the loss of the MCO as they are now. But 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 AdministrationConfirmation 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. The bias favors information that would support directly the achievement of those primary objectives. Decisions tend, for example, to discount warnings of technical debt issues. They also tend to underfund technical debt assessments, and set aside advice regarding avoiding debt formation in current projects.
An example
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.
Last words
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.
[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.
[Beardsell 2010] Julie Beardsell. “IT Backsourcing: is it the solution to innovation?”, SMC Working Paper Series, Issue: 02/2010, Swiss Management Center University, 2010.
[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.
[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.
[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
[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.
[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.
[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, 369-381, 2002.
[Willcocks 2004] L. Willcocks, J. Hindle, D. Feeny, and M. Lacity. “IT and Business Process Outsourcing: The Knowledge Potential,” Information Systems Management 21:3, 7-15, 2004.
