Feature bias: unbalanced concern for capability vs. sustainability

Enterprise decision-makers affected by feature bias tend to harbor distorted views of the importance of new capability development compared to technical debt management. This tendency is likely due to the customer’s relative sensitivity to features, and relative lack of awareness of sustainability. Whatever the cause, customers tend to be more attracted to features than they are to indicators of sound technical debt management and other product sustainability practices. This tendency puts decision-makers at risk of feature bias: unbalanced concern for capability vs. sustainability.

Alaska crude oil production 1990-2015
Alaska crude oil production 1990-2015. This chart [Yen 2015] displays Alaska crude oil produced and shipped through the Trans Alaska Pipeline System (TAPS) from 1990 to 2015. Production had dropped by 75% in that period, and the decline is projected to continue. In January 2018, in response to pressure from Alaskan government officials and the energy industry, the U.S. Congress passed legislation that opened the Arctic National Wildlife Refuge to oil exploration, despite the threat to ecological sustainability that exploration poses. If we regard TAPS as a feature of the U.S. energy production system, we can view its excess capacity as a source of feature bias bias, creating pressure on decision-makers to add features to the U.S. energy system instead of acting to enhance the sustainability of Alaskan and global environmental systems [Wight 2017].
Changes in cost accounting could mitigate some of this feature bias by projecting more accurately total MICs based on historical data and sound estimation. I’ll explore possible accounting changes later in this post, and in future posts; meanwhile, let’s explore the causes and consequences of the distorted perspective I call feature bias.

For products or services offered for sale outside the enterprise, the sales and marketing functions of the enterprise represent the voice of the customer [Gaskin 1991]. But customers are generally unaware of product or service attributes that determine maintainability, extensibility, or cybersecurity — all factors that affect the MICs for technical debt. On the other hand, customers are acutely aware of capabilities — or missing or defective capabilities — in products or services. Customer comments and requests, therefore, are unbalanced in favor of capabilities as compared to maintainability, extensibility, cybersecurity, and other attributes related to sustainability. The sales and marketing functions tend to accurately transmit this unbalanced perspective to decision-makers and technologists.

An analogous mechanism prevails with respect to infrastructure and the internal customers of that infrastructure. Internal customers tend to be more concerned with capabilities — and missing capabilities — than they are with sustainability of the processes and systems that deliver those capabilities. Thus, pressure from internal customers on the developers and maintainers of infrastructure elements tends to emphasize capability at the expense of sustainability. The result of this imbalance is pressure to allocate excessive resources to capability enhancement, compared to activities that improve maintainability, extensibility, or cybersecurity, and which therefore would aid in controlling or reducing technical debt and its MICs.

Nor is this the only consequence of feature bias. It provides unrelenting pressure for increasing numbers of features, despite the threats to architectural coherence and overall usability that such “featuritis” or “featurism” present. Featurism leads, ultimately, to feature bloat, and to difficulties for users, who can’t find what they need among the clutter of features that are often too numerous to document. For example, in Microsoft Word, many users are unaware that Shift+F5 moves the insertion point and cursor to the point in the active document that was last edited, even if the document has just been freshly loaded into Word. Useful, but obscure.

Feature bias, it must be noted, is subject to biases itself. The existing array of features appeals to a certain subset of all potential customers. Because it is that subset that’s most likely to request repair of existing features, or to suggest additional features, the pressure for features tends to be biased in favor of the needs of the most vociferous segments of the existing user base. That is, systems experience pressure to evolve to better meet the needs of existing users, in preference to meeting the needs of other stakeholders or potential stakeholders who might be even more important to the enterprise than are the existing users. This bias in feature bias presents another risk that can affect decision-makers.

Organizations can take steps to mitigate the risk of feature bias. An example of such a measure might be the use of focus groups to study how education in sustainability issues affects customers’ perspectives relative to feature bias. Educating decision makers about feature bias can also reduce this risk.

At the enterprise scale, awareness of feature bias would be helpful, but awareness alone is unlikely to counter its detrimental effects, which include underfunding of technical debt management efforts. Eliminating the source of feature bias is extraordinarily difficult, because customers and potential customers aren’t subject to enterprise policy. Feature bias and feature bias bias are therefore givens. To mitigate the effects of feature bias, we must adopt policies that compel decision-makers to consider the need to deal with technical debt. One possible corrective action might be improvement of accounting practices for MICs, based, in part, on historical data. For example, since there’s a high probability that any project might produce new technical debt, it might be prudent to fund the retirement of that debt, in the form of reserves, when we fund the project. And if we know that a project has encountered some newly recognized form of technical debt, it might be prudent to reserve resources to retire that debt as soon as possible. Ideas such as these can rationalize resource allocations with respect to technical debt.

These two examples illustrate what’s necessary if we want to mitigate the effects of feature bias. They also illustrate just how difficult such a task will be.

References

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

Other posts in this thread

Unrealistic definition of done

Last updated on February 1st, 2018 at 07:27 am

Many an enterprise culture includes, perhaps tacitly, an unrealistic definition of done. When an enterprise culture assumes a definition of done for projects that excludes — or fails to adequately acknowledge — attributes related to sustainability of deliverables, technical debt expands inexorably. In most organizations, the definition of done for projects includes meeting the attributes that most internal customers understand and care about. These attributes might not include sustainability [Guo 2011]. Indeed, even among technologists, the definition of done might not enjoy precise consensus [Wake 2002].

The 2009 Ford Focus SES coupe (North America) engine bay
The 2009 Ford Focus SES coupe (North America) engine bay. Gone are the days when typical owners could learn how to maintain their own vehicles. Engines have become so complex that even experienced mechanics must be trained to maintain engines with which they’re unfamiliar. Since these vehicles are being offered for sale to consumers, clearly their manufacturers regard their designs as “done.” But is technical debt a factor in the growing complexity of modern motor vehicle engines? It’s probably present in their software, and it would be most surprising if we found no technical debt in the mechanical design. Photo (cc) Porsche997SBS courtesy Wikimedia.

Because attributes related to sustainability of deliverables are less well understood by internal customers — indeed, by nearly everyone — it is perhaps unsurprising that sustainability might not receive the attention it needs. Applying scarce resources to enhance attributes the customer doesn’t understand, and cares about less, will always be difficult.

To gain control of technical debt, we must redefine done to include addressing sustainability of deliverables. Although there may be many ways to accomplish this, none will be easy. Resolution will involve, inevitably, educating internal customers so that they understand enough about sustainability to enable them to justify paying for it.

The typical definition of done for most projects ensures only that the deliverables meet the requirements. Because requirements usually omit reference to retiring newly incurred non-strategic technical debt, projects are often declared complete with incremental technical debt still in place. A similar problem prevails with respect to legacy technical debt.

A more insidious form of this problem is intentional shifting of the definition of done. This happens when the organization has adopted a reasonable definition of done that allows for addressing sustainability, but under severe time pressure, the definition is “temporarily” amended to allow the team to declare the effort complete, even though sustainability issues remain unaddressed.

For most projects, three conditions conspire to create steadily increasing levels of non-strategic technical debt. First, for most tasks, the definition of done is that the deliverables meet the project objectives, or at least, they meet them well enough. Second, typical project objectives don’t restrict levels of newly incurred non-strategic technical debt, nor do they demand retirement of incidentally discovered legacy technical debt. Third, budget authority usually terminates upon acceptance of delivery. These three conditions, taken together, restrain engineering teams from immediately retiring any debt they incur and from retiring — or documenting or reporting — any legacy technical debt they encounter while fulfilling other requirements.

For example, for one kind of incremental technical debt — what Fowler calls [Fowler 2009] Inadvertent/Prudent (“Now we know how we should have done it”) — the realization that debt has been incurred often occurs after the task is “done.” If budget authority has terminated, there are no resources available — financial or human — to retire that form of technical debt.

Unless team members document the technical debt they create or encounter, after they move on to their next assignments, the enterprise is likely to lose track of the location and nature of that debt. A more realistic definition of done would enable the team to continue working post-delivery to retire, or at least document, any newly incurred non-strategic technical debt or incidentally encountered legacy technical debt. Moreover, strategic technical debt — technical debt incurred intentionally for strategic reasons — is also often left in place. Although it, too, must be addressed eventually, the widespread definition of done doesn’t address it.

Policymakers are well positioned to advocate for the culture transformation needed to redefine done.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

Other posts in this thread

Stovepiping can lead to technical debt

Last updated on February 1st, 2018 at 07:28 am

Stovepiping can lead to technical debt. Actual stovepipes — the tubes that vent exhaust from stoves — serve as a metaphor for the flow of information in “stovepipe” organizations. In “stovepipe” organizations, information flows predominantly (or only) up or down along the parallel chains of command, and rarely (or never) from a point in one chain of command across to some other chain of command [Waters 2010]. The stovepipe metaphor is imperfect, in the sense that in actual stovepipes, smoke and fumes rarely flow downwards. By contrast, in organizations, some information does flow down the chains of command. But the metaphor does clarify the problem that whatever the organization learns in one metaphorical stovepipe isn’t easily transferred to other metaphorical stovepipes.

A wood-burning stove in a farm museum
A wood-burning stove in a farm museum in Lower Bavaria (German: Niederbayern), which is one of the seven administrative regions of Bavaria, Germany. The stovepipe, which is the black tube running upwards from the stove, channels smoke and fumes out of the kitchen into the chimney, and then, presumably, out of the farmhouse.

Stovepiping can occur in both organizational structures and in engineered systems. These two forms of stovepiping are intimately related, and both can lead to uncontrolled formation of new technical debt, or increased persistence of existing technical debt.

In organizational structures, stovepiping occurs when similar capabilities are implemented in elements of two or more different organizational units that act relatively independently of each other. An example is the dispersal of some elements of the IT function out into IT’s customers. When independent organizations have similar technical needs, they’re at risk of independently implementing technological capabilities that duplicate each other, at least in some respects.

In engineering, stovepiping occurs, for example, when two or more technological assets are managed and maintained independently [McGovern 2003]. In that situation, distinct engineering efforts working on those assets might happen to solve the same problem, possibly in two different ways, with each party either ignorant, or possibly disparaging, of the other’s efforts.

In whichever way duplication of technological capability comes about, it can lead to increasing levels of technical debt, or to increased persistence of technical debt. This happens because the organization might be required to execute future maintenance or enhancement multiple times — once for each instance of the technical artifact. That exposes the organization to additional cost, additional load on its staff, and additional risk of creating defects and incurring liability, compared to a situation in which technical assets are shared among all who need them.

The problem is actually even more worrisome. First, in the case of a defect found in one version of a technological artifact, it’s possible that the people who are aware of the defect might not realize that another version of the artifact exists. If that other version also has an analogous defect, its defect might go unrecognized for some time, with all the usual attendant negative consequences. Second, in the case of a necessary extension of the artifact’s capabilities, the maintainers of one version might recognize the need for an extension, and implement it. Meanwhile the maintainers of other versions might not recognize the need for extension. They might not take action until something bad happens or a possibly urgent need arises. It’s easy to conjure other unfavorable — and costly — scenarios.

In engineering more generally, stovepiping can occur internally in systems, even though only one business unit is involved, and even though the stovepiped artifacts serve purposes invisible to the world outside the system. This can occur whenever communication is weak between the teams designing or maintaining the portions of the system that host the similar artifacts. For those familiar with the Apollo XIII incident, the incompatibility of the two carbon dioxide scrubbers in the command module and the lunar excursion module serves as an example of the risks of technical stovepiping.

When distinct business units or functions operate their own engineering or IT functions, or when they depend on a shared engineering function but require similar work, there is an elevated probability of duplication of technological assets or capabilities. This happens when the organizational structure, or the timing of the work, encourages separation of the engineering efforts. Engineering or IT functions operated separately under the control of distinct business units or functions can clearly produce duplicated capabilities. However, duplication can also occur when the engineering function is shared across distinct business units or functions, but the actual people and teams performing the work differ for different efforts, and when communication is weak between those teams. This can happen whether or not the efforts are conducted contemporaneously.

Because identifying these forms of technical debt after they’re created is notoriously difficult, preventing their formation is preferable to trying to detect them post-implementation. Prevention is possible if the enterprise establishes mechanisms that facilitate consultation and sharing among elements of different, separately operated technology development or maintenance functions. In other words, the organization must “break” the stovepipes — no mean feat, politically speaking.

Another challenge, of course, is providing resources for such sharing mechanisms, because preventing technical debt is rarely recognized as a value generator. If it were so recognized, the resources would likely appear. Changes in cost accounting might make such recognition more likely.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

[McGovern 2003] James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture, Upper Saddle River, New Jersey: Prentice Hall PTR, 2003.

Order from Amazon

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Waters 2010] Donald Waters. Global Logistics: New Directions In Supply Chain Management, 6th Edition, London: Kogan Page Limited, 2010.

Order from Amazon

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

Other posts in this thread

The Dunning-Kruger effect can lead to technical debt

Last updated on February 14th, 2018 at 12:39 pm

The Dunning-Kruger effect [Kruger 1999] can lead to formation or persistence of technical debt in two ways. First, it can cause technologists or their managers to overestimate their ability to maintain the resource focus needed for retiring technical debt in a timely fashion. Second, it can cause senior managers to be reluctant to accede to resource requests of technologists and their managers in support of technical debt management programs.

Cropped detail from Charles Robert Darwin, a painting by John Collier
Cropped detail from Charles Robert Darwin, a painting by John Collier (1850-1934), given to the National Portrait Gallery, London, in 1896. Darwin writes, in The Descent of Man (1871): “… ignorance more frequently begets confidence than does knowledge …” which is the essence of the Dunning-Kruger effect. Image courtesy WikiQuote.

Kruger and Dunning conducted experiments that yielded results consistent with the following four principles (paraphrasing):

  1. Incompetent individuals, compared to their more competent peers, tend to dramatically overestimate their own ability and performance
  2. Incompetent individuals, compared to their more competent peers, tend to be less able to gain insight into their own true levels of performance
  3. Incompetent individuals can gain insight about their shortcomings, but, paradoxically, this comes about by gaining competence
  4. Incompetent individuals, compared to their more competent peers, are less able to recognize competence when they see it

The first three principles lead to distorted assessments of one’s own capabilities. The fourth principle leads to distorted assessments of the capabilities of others.

As an example of distorted self-assessment, consider a team or its managers who must undertake retirement of some types of technical debt in the course of enhancing or repairing an asset. Such a task plan seems at first to offer efficiencies, because the engineers can readily make both kinds of changes at one go. Metaphorically, if we must go to the store for milk, we can also pick up bread while we are there, rather than making two trips.

However, modifying an existing complex technological asset is unlike shopping for bread and milk. The two kinds of modifications — debt retirement and asset enhancement or repair — might seem at first to be separable, and often they are. But if they are not separable, and the two tasks are undertaken together, testing and debugging can become extremely complicated, because of interactions between defects in the two kinds of modifications. Under some circumstances, an experienced team and its managers might be more likely to anticipate these difficulties. An inexperienced team and its managers might be more likely to underestimate the difficulties, as a consequence of the Dunning-Kruger effect. Budget and schedule overruns are possible consequences of underestimating the complexity of the problem.

As an example of the fourth principle above, the Dunning-Kruger effect can cause some decision-makers to discount the warnings and resource requests of engineers and their managers. Decision-makers who are unsophisticated in matters related to technical debt must nevertheless assess the validity of the requests for resources. In making these assessments, these decision-makers may be disadvantaged for a number of reasons, including the following:

  • Decision-makers might hold any of a number of mistaken beliefs about technical debt. For example, many believe that the main causes of technical debt are poor decisions by engineering managers. And others believe that technical debt is the result of slovenly work habits of engineers. Those who hold such beliefs might be reluctant to allocate yet more resources to engineers to address the problem of technical debt.
  • If the advocates of resources for technical debt management are not fully informed about the strategic direction of the enterprise, their requests might be inconsistent with enterprise strategy. As a result of a cognitive bias [Kahneman 2011] known as the halo effect [Thorndike 1920], decision-makers might tend to discount valid portions of the technologists’ proposals, because some portions of those proposals don’t take enterprise strategy into account properly.
  • Decision-makers might be affected by unrealistic optimism [Weinstein 1996], also known as optimism bias. It’s a cognitive bias that can cause them to discount the sometimes-vivid warnings of technologists about the unfavorable consequences of failing to provide technical debt management resources.

Investigations of the degree of correlation between burdens of technical debt and the incidence of rejected or severely curtailed proposals for resources to support technical debt management programs could determine the significance of the Dunning-Kruger effect relative to the problem of technical debt. Also rewarding would be a survey of the nearly 200 known cognitive biases, to determine which of them might be most likely to affect decision-making relative to technical debt, and how best to mitigate the risks they present.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

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

Order from Amazon

Cited in:

[Kruger 1999] J. Kruger and D. Dunning. “Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments,” Journal of Personality and Social Psychology, 77(6), 1121-1134 (1999).

Cited in:

[McGovern 2003] James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture, Upper Saddle River, New Jersey: Prentice Hall PTR, 2003.

Order from Amazon

Cited in:

[Thorndike 1920] E.L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4(1), 25-29 (1920). doi:10.1037/h0071663

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Waters 2010] Donald Waters. Global Logistics: New Directions In Supply Chain Management, 6th Edition, London: Kogan Page Limited, 2010.

Order from Amazon

Cited in:

[Weinstein 1996] Neil D. Weinstein and William M. Klein. “Unrealistic Optimism: Present and Future,” Journal of Social and Clinical Psychology 15(1), 1-8 (1996). doi:10.1521/jscp.1996.15.1.1

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

Other posts in this thread

The concept of MICs

Last updated on December 11th, 2017 at 10:39 am

Using the term interest to refer to the metaphorical interest charges that are associated with a technical debt is risky. The risk arises from confusing the properties of financial interest with the properties of the metaphorical interest charges on technical debt. Using an alternative term that makes the metaphor obvious can limit this risk. One such term is metaphorical interest charges, or for convenience, MICs.

Loose change
Loose change. The MICs on technical debt are  accumulated in two ways: (a) as “loose change,” namely, small bits of lost time, delays, and depressed productivity; and (b) as major blows to enterprise vitality in the form of lost revenue, delayed revenue, and missed market opportunities. Hard to say which category does more damage.

MICs aren’t interest charges in the financial sense; rather, the MICs of a technical debt represent the total of reduced revenue, incidental opportunity costs, and increased costs of all kinds borne by the enterprise as a consequence of carrying that technical debt. (Actually, now that I think of it, MICs can include financial interest charges if we find it necessary to borrow money as a consequence of carrying technical debt.) Because the properties of MICs are very different from the properties of financial interest charges, we use the term MICs to avoid confusion with the term interest from the realm of finance.

Briefly, MICs are variable and often unpredictable [Allman 2012]. MICs differ from interest charges on financial debt for at least six reasons. For any particular class of technical debt:

I examine each of these properties in more detail in the posts listed above.

References

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

Available: here; Retrieved: March 16, 2017

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

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

Order from Amazon

Cited in:

[Kruger 1999] J. Kruger and D. Dunning. “Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments,” Journal of Personality and Social Psychology, 77(6), 1121-1134 (1999).

Cited in:

[McGovern 2003] James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture, Upper Saddle River, New Jersey: Prentice Hall PTR, 2003.

Order from Amazon

Cited in:

[Thorndike 1920] E.L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4(1), 25-29 (1920). doi:10.1037/h0071663

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Waters 2010] Donald Waters. Global Logistics: New Directions In Supply Chain Management, 6th Edition, London: Kogan Page Limited, 2010.

Order from Amazon

Cited in:

[Weinstein 1996] Neil D. Weinstein and William M. Klein. “Unrealistic Optimism: Present and Future,” Journal of Social and Clinical Psychology 15(1), 1-8 (1996). doi:10.1521/jscp.1996.15.1.1

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

Related posts

Glossary and Terminology

Last updated on February 16th, 2018 at 07:25 am

Even though technical debt has been with us for a very long time—probably since the time we began inventing technologies—the study of technical debt is relatively new. Ward Cunningham coined the term technical debt in 1992, and its meaning has evolved since then. Because universally accepted definitions for the term and associated concepts have not yet emerged, it seems necessary to have a page on this site that collects definitions.

Class of technical debt

On occasion, we speak of classes of technical debt and instances of that class. This can be confusing, because the words class and instance have particular meanings in software engineering. That’s not the sense in which we use the terms here. In this blog, a class of technical debt is just a collection of instances of the same kind of debt. For example, consider the “ghost ramp” described in “Technical debt in the highway system.” It belongs to the class of ghost ramps. If we were maintaining the highway system of Massachusetts, it might be convenient to consider the class of ghost ramp technical debt if we want to let a contract to demolish all ghost ramps. Each ghost ramp would then be an instance of that class.

Cognitive bias

A cognitive bias is the human tendency to make systematic errors based not on evidence, but on factors related to the thought process. Psychologists have identified and demonstrated hundreds of cognitive biases, including several that could plausibly explain failures in priority setting for technical debt retirement projects.

Incremental technical debt

Incremental technical debt is technical debt that’s incurred in the course of work currently underway or just recently completed. For example, in an apartment building hallway renovation project, workmen did insert expansion joints in the sheetrock they replaced, but on the first three floors they completed, the joints were too widely separated. The remaining 22 floors were done correctly. Nine additional joints on each of the incorrect floors must be inserted eventually. The missing joints, which constitute incremental technical debt, will be inserted after the job is completed.

Instance of technical debt

See “Class of technical debt

Legacy technical debt

Legacy technical debt is technical debt associated with an asset, and which exists in any form prior to undertaking work on that asset. For example, in planning a project to renovate the hallways and common areas of a high-rise apartment building, Management discovers that beneath the existing carpeting is a layer of floor tile containing asbestos. Management has decided to remove the tile. In this context, the floor tile can be viewed as legacy technical debt. It isn’t directly related to the objectives of the current renovation, but removing it will enhance the safety of future renovations, enable certification of the building as asbestos-free, and reduce the cost of eventual demolition.

MICs, or metaphorical interest charges

MICs are the metaphorical interest charges associated with a technical debt. They aren’t interest charges in the financial sense; rather, the MICs of a technical debt represent the total of reduced revenue, lost opportunities, and increased costs of all kinds borne by the enterprise as a consequence of carrying that technical debt. Because the properties of MICs are very different from the properties of financial interest charges, we use the term MICs to avoid confusion with the term interest from the realm of finance. More: “How financial interest charges differ from interest charges on technical debt

MPrin, or metaphorical principal

The MPrin of a technical debt at a give time T is the total cost of retiring that debt at time T. The total cost includes all cost factors: labor, equipment, service interruptions, revenue delays, anything. It even includes the ongoing costs of repairing defects introduced in the debt retirement process. More: “The metaphorical principal of a technical debt

Non-strategic technical debt

Non-strategic technical debt is technical debt that appears in the asset without strategic purpose. We tend to introduce non-strategic technical debt by accident, or as the result of urgency, or from changes in standards, laws, or regulations—almost any source other than asset-related engineering purposes. And at times, it appears in the asset as a result of external events beyond the boundaries of the enterprise. More: “Non-technical precursors of non-strategic technical debt

The planning fallacy

The planning fallacy is a cognitive bias that causes planners to underestimate costs and schedules, and over-promise benefits, because they pay too little heed to past experience on similar efforts, and rely too much on what they believe will happen on the effort they’re planning. First identified in a 1977 report by Daniel Kahneman and Amos Tversky [Kahneman 1979a] [Kahneman 1979b]. More:  “Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma

Policy

Organizational policy is the framework of principles that guide policymakers, decision makers, and everyone in the organization as they carry out their responsibilities. Policy might be written or not, but written policy is more likely to consistently adhered to. Interestingly, the body of organizational policy is itself subject to accumulating technical debt. More: “What is policy?

Policymaker

As I use the term in this blog, a policymaker is someone who is responsible for developing, revising, or approving organizational policies that affect technical debt management. More: “Who are the policymakers?

Source and target components of a metaphor

In a metaphor of the form “A is B,” the source is the element whose attributes are being attributed to the target. For example, in “my son’s room is a war zone,” the source is the war zone, and the target is my son’s room.  More: “The structure of metaphors

Technical debt

Technical debt is any technological element that contributes, through its existence or through its absence, to lower productivity or to a higher probability of defects during development, maintenance, or enhancement efforts, or which depresses velocity in some other way, and which we would therefore like to revise, repair, replace, rewrite, create, or re-engineer for sound engineering reasons. It can be found in—or it can be missing from—software, hardware, processes, procedures, practices, or any associated artifact, acquired by the enterprise or created within it. More: “A policymaker’s definition of technical debt

Technological communication risk

Technological communication risk is the risk that, for whatever reason, knowledgeable people within the enterprise don’t communicate important knowledge to the people who need it, or the people who need it aren’t receptive to it. More: “Technological communication risk

References

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

Available: here; Retrieved: March 16, 2017

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

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

Cited in:

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

Cited in:

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

Order from Amazon

Cited in:

[Kruger 1999] J. Kruger and D. Dunning. “Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments,” Journal of Personality and Social Psychology, 77(6), 1121-1134 (1999).

Cited in:

[McGovern 2003] James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture, Upper Saddle River, New Jersey: Prentice Hall PTR, 2003.

Order from Amazon

Cited in:

[Thorndike 1920] E.L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4(1), 25-29 (1920). doi:10.1037/h0071663

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Waters 2010] Donald Waters. Global Logistics: New Directions In Supply Chain Management, 6th Edition, London: Kogan Page Limited, 2010.

Order from Amazon

Cited in:

[Weinstein 1996] Neil D. Weinstein and William M. Klein. “Unrealistic Optimism: Present and Future,” Journal of Social and Clinical Psychology 15(1), 1-8 (1996). doi:10.1521/jscp.1996.15.1.1

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

Technical debt in software engineering

Ward Cunningham, who coined the technical debt metaphor

Last updated on November 23rd, 2017 at 08:27 pm

Ward Cunningham, who coined the technical debt metaphor
Ward Cunningham, who coined the technical debt metaphor. Photo (cc) Carrigg Photography.

Ward Cunningham, who coined the technical debt metaphor in the context of developing a software asset [Cunningham 1992] [Cunningham 2011], observed that when the development process leads to new learning, re-executing the development project — or parts of the project — could lead to a better result. For this reason, among others, newly developed operational software assets can contain, embody, or depend upon artifacts that, in hindsight, the developers recognize could be removed altogether, or could be replaced by more elegant, effective, or appropriate forms that can enhance maintainability, defensibility, and extensibility. To deploy the asset in pre-hindsight condition would entail an obligation to return to it in the future to implement the improvements revealed by that hindsight. That obligation is Cunningham’s conception of the asset’s technical debt.

Fowler’s technical debt quadrant
Fowler’s technical debt quadrant. Intentionality is the vertical axis; Wisdom is horizontal.

In the decades since Cunningham coined the term, the meaning of technical debt has evolved to include much more than Cunningham’s original concept. Martin Fowler developed a 2×2 matrix (Intentionality x Wisdom) that describes four different pathways that lead to technical debt creation. Cunningham’s concept corresponds to what Martin Fowler describes as, “now we know how we should have done it” [Fowler 2009].

At a conference in Dagstuhl, Germany (“Managing Technical Debt in Software Engineering”) in 2016, leading experts in software technical debt research developed a verbal definition of technical debt for software-intensive systems [Avgeriou 2016]:

In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.

With the definition of technical debt enlarged in this way, software engineers can focus on instances of software technical debt that reduce enterprise productivity and agility. But is this definition sufficient as a foundation for enterprise policy? I explore that question in “A policymaker’s definition of technical debt.”

References

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

Available: here; Retrieved: March 16, 2017

Cited in:

[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.

Available: here; Retrieved: March 10, 2017.

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Cunningham 2011] Ward Cunningham. “Ward Explains Debt Metaphor” (video; here; ).

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

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

Cited in:

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

Cited in:

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

Order from Amazon

Cited in:

[Kruger 1999] J. Kruger and D. Dunning. “Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments,” Journal of Personality and Social Psychology, 77(6), 1121-1134 (1999).

Cited in:

[McGovern 2003] James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture, Upper Saddle River, New Jersey: Prentice Hall PTR, 2003.

Order from Amazon

Cited in:

[Thorndike 1920] E.L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4(1), 25-29 (1920). doi:10.1037/h0071663

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Waters 2010] Donald Waters. Global Logistics: New Directions In Supply Chain Management, 6th Edition, London: Kogan Page Limited, 2010.

Order from Amazon

Cited in:

[Weinstein 1996] Neil D. Weinstein and William M. Klein. “Unrealistic Optimism: Present and Future,” Journal of Social and Clinical Psychology 15(1), 1-8 (1996). doi:10.1521/jscp.1996.15.1.1

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

What is policy?

Last updated on December 16th, 2017 at 06:29 am

DuBrin define policies as “… general guidelines to follow when making decisions and taking action” [DuBrin 2016]. Some policies are written, some are unwritten. Some have names or identifiers, some don’t. For organizations seeking to gain control of technical debt, written policies are probably a good idea, for two reasons:

  • Many people affected by technical debt policies are probably unfamiliar with the technical debt concept. A written policy is more likely to be communicated uniformly to everyone.
  • The effort spent devising a written policy is likely to surface ambiguities, confusions, and varying needs. Resolving these issues during the policy formation process is better for the organization than resolving them during the deployment process.

A useful policy is clear. It uses terminology that is simple and well defined.

References

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

Available: here; Retrieved: March 16, 2017

Cited in:

[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.

Available: here; Retrieved: March 10, 2017.

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Cunningham 2011] Ward Cunningham. “Ward Explains Debt Metaphor” (video; here; ).

Cited in:

[DuBrin 2016] Andrew J. DuBrin. Essentials of Management, Tenth Edition. Indianapolis, Indiana: Wessex Press, 2016.

Order from Amazon

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

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

Cited in:

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

Cited in:

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

Order from Amazon

Cited in:

[Kruger 1999] J. Kruger and D. Dunning. “Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments,” Journal of Personality and Social Psychology, 77(6), 1121-1134 (1999).

Cited in:

[McGovern 2003] James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture, Upper Saddle River, New Jersey: Prentice Hall PTR, 2003.

Order from Amazon

Cited in:

[Thorndike 1920] E.L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4(1), 25-29 (1920). doi:10.1037/h0071663

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Waters 2010] Donald Waters. Global Logistics: New Directions In Supply Chain Management, 6th Edition, London: Kogan Page Limited, 2010.

Order from Amazon

Cited in:

[Weinstein 1996] Neil D. Weinstein and William M. Klein. “Unrealistic Optimism: Present and Future,” Journal of Social and Clinical Psychology 15(1), 1-8 (1996). doi:10.1521/jscp.1996.15.1.1

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

Related posts

Who are the policymakers?

Last updated on November 21st, 2017 at 08:34 am

As we use the term in this blog, a policymaker is someone who is responsible for developing, revising, or approving organizational policies that affect technical debt management. Organizational policy is the framework of principles that guide policymakers, decision makers, and everyone in the organization as they carry out their responsibilities.

Some organizational policies that do not even mention technical debt can affect the way the organization manages technical debt. For this reason, all policymakers are potentially involved in formulating policy that affects the ability of the organization to manage technical debt.

References

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

Available: here; Retrieved: March 16, 2017

Cited in:

[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.

Available: here; Retrieved: March 10, 2017.

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Cunningham 2011] Ward Cunningham. “Ward Explains Debt Metaphor” (video; here; ).

Cited in:

[DuBrin 2016] Andrew J. DuBrin. Essentials of Management, Tenth Edition. Indianapolis, Indiana: Wessex Press, 2016.

Order from Amazon

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Gaskin 1991] Steven P. Gaskin, Abbie Griffin, John R. Hauser, Gerald M. Katz, and Robert L. Klein. “Voice of the Customer,” Marketing Science 12(1), 1-27 (1991).

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

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

Cited in:

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

Cited in:

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

Order from Amazon

Cited in:

[Kruger 1999] J. Kruger and D. Dunning. “Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments,” Journal of Personality and Social Psychology, 77(6), 1121-1134 (1999).

Cited in:

[McGovern 2003] James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture, Upper Saddle River, New Jersey: Prentice Hall PTR, 2003.

Order from Amazon

Cited in:

[Thorndike 1920] E.L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4(1), 25-29 (1920). doi:10.1037/h0071663

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Waters 2010] Donald Waters. Global Logistics: New Directions In Supply Chain Management, 6th Edition, London: Kogan Page Limited, 2010.

Order from Amazon

Cited in:

[Weinstein 1996] Neil D. Weinstein and William M. Klein. “Unrealistic Optimism: Present and Future,” Journal of Social and Clinical Psychology 15(1), 1-8 (1996). doi:10.1521/jscp.1996.15.1.1

Cited in:

[Wight 2017] Philip Wight. “How the Alaska Pipeline Is Fueling the Push to Drill in the Arctic Refuge,” YaleE360, Yale School of Forestry & Environmental Studies, November 16, 2017.

Available: here; Retrieved: February 8, 2018

Cited in:

[Yen 2015] Terry Yen, Laura Singer. “Oil exploration in the U.S. Arctic continues despite current price environment,” Today in Energy blog, U.S. Energy Information Administration, June 12, 2015.

Available: here; Retrieved: February 8, 2018.

Cited in:

Related posts