Category: Terminology

Posts that provide the meanings of terms related to technical debt, as used in this blog.

Posted on

Refactoring for policymakers

Policymakers whose areas of expertise have little or no overlap with software engineering might be at a bit of a disadvantage when the conversation turns to refactoring. That can happen when the matter at hand involves software assets that carry technical debt, because the engineers are likely to argue for resources and time to be set aside for refactoring. Other “re” words are also likely to pop up: restructuring, re-architecting, rewriting, replacing, repairing, retiring, retreating, and re-engineering are examples. Some of these are clear—and clearly unaffordable—but some are less clear. What’s needed is a lucid explanation of refactoring for policymakers.

An LED traffic light
An LED traffic light. This type of signal is more efficient and more cheaply and easily maintained than incandescent signals. But in terms of traffic control, LED signals and incandescent signals are equivalent.

To refactor1 a software asset is to improve its internal structure without altering its external behavior [Fowler 1999]. The improvements usually relate to maintainability or extensibility, and for software, that usually requires improving the readability of its code (for engineers), though it might entail some minor changes of other kinds. Instance by instance, these improvements are usually small in scale. Even so, a refactoring effort might involve small changes throughout the entire asset or throughout an entire suite of assets.

Although we usually regard refactoring as a software-related activity, refactoring, like technical debt, is a concept that can apply to any technological asset. To render the refactoring concept useful for assets other than software, we must be a bit more precise about the effects of the changes involved in refactoring.

A more general definition of refactoring

Refactoring an asset inherently changes that asset; what distinguishes refactoring from other kinds of changes is the observability of the changes. For the definition of refactoring used in software engineering, the changes are observable only to the software engineers who maintain or enhance the asset.

Here’s a definition of refactoring that’s somewhat more widely applicable:

To refactor a technological asset is to apply a series of small, behavior-preserving changes to improve the structure of the asset in ways that have effects that aren’t ordinarily observable externally. When effects are observable externally, they’re very specific, usually related to attributes such as quality and usability.

For example, after a municipality replaces incandescent traffic lights with LED traffic lights, there’s no effect on traffic control. To the untrained eye, or to the trained eye that’s otherwise preoccupied, the change isn’t noticeable. But those responsible for signal maintenance or for monitoring operating costs will notice significant advantages. With respect to traffic flow, we can therefore regard the change to LED traffic lights as a refactoring of the traffic control system.

Refactoring in manufactured consumer items can be more difficult to recognize, because the useful life of the item so often ends while the item is still in the hands of the consumer. For example, we might ask how to refactor a certain subassembly of an automobile that’s already in service. Some writers have identified the vehicle recall as a kind of refactoring [Shroyer 2016]. But I prefer to regard successive models of manufactured items as containing refactorings of earlier models.

For example, in robot vacuum cleaners, the iRobot Roomba is now available in a ninth-generation “series,” though the exact number of the generations depends on what one counts as first-generation. In laptop computers, most manufacturers’ offerings do change from one model to the next version of that model. Some of these changes are more significant than what we might consider to be refactoring, such as Apple’s removal of the MagSafe power connector [Spence 2018]. For laptops, more likely to be a refactoring would be a change to a slightly more efficient internal fan.

Other applications of the refactoring concept

The refactoring concept can also apply to processes. Indeed, failure to refactor business processes is sometimes a cause of needless complexity, high maintenance costs, and other difficulties in technological assets that must interact with processes that need refactoring [Distante 2014]. The refactoring concept—that is, to improve internal structures while preserving external behavior—might even find use in organizational restructuring and debt restructuring.

Endnote

[1] One might wonder why this process is called refactoring. Martin Fowler, the author of the classic 1999 book about refactoring, has investigated the etymology of the word and concludes that it likely arose in the Forth and Smalltalk communities in the 1980s. [Fowler 2003] Jump back to the text

References

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

Cited in:

Other posts in this thread

Related posts

  • Refactoring for policymakers
    To refactor an asset is to apply a series of small, behavior-preserving changes to improve the structure of the asset. When effects are observable externally, they’re very specific, usually related to attributes such as quality and usability.
  • Outsourcing Technical Debt Retirement Projects
    Because situational details are so important, there’s no formula for choosing to outsource technical debt retirement projects. But there are guidelines.
  • Automation-assisted technical debt retirement
    When we retire technical debt from assets, service disruptions might be necessary. Automating some procedures can minimize those disruptions and avoid errors and rework.
  • Controlling incremental technical debt
    Organizations are more likely to gain control of their legacy technical debt portfolio if they begin by controlling the transformation of incremental technical debt into legacy technical debt.
  • Retiring localizable technical debt
    Technical debt that appears as discrete chunks—localizable technical debt—is more readily retired, because we can do it incrementally, piece by piece. It’s a particularly manageable challenge.
  • Retiring technical debt in irreplaceable assets
    For some assets, we can’t allow debt to persist, and we can’t afford replacements. We must retire the debt. This post begins exploring what it takes to design projects to retire technical debt in irreplaceable assets.
Posted on

Leverage points for technical debt management

Last updated on December 11th, 2018 at 10:40 am

Adopting a program of technical debt management entails significant change to the system we call the enterprise. The problem can seem so daunting that we don’t know where to begin. The places to begin are the places where the change agents have greatest leverage—what systems analysts call leverage points. Consider this scenario.

You’re sitting in the kickoff meeting of the new Technical Debt Management Task Force. The CEO is talking about how she realized that the company had a technical debt problem. It was when the Marigold project went through delay after delay, and was finally declared done, with multiple objectives waived. She’s saying something about, “we were trying to do backflips with millstones around our necks. So I want this task force to show us how to get rid of the millstones, and then get rid of them.”

McMurdo Station, Antarctica, as seen from nearby Observation Hill
McMurdo Station, Antarctica, as seen from nearby Observation Hill. The United States Antarctic Program, a unit of the National Science Foundation, operates the station. It can house as many as 1258 people in Summer. Photo (cc) Gaelen Marsden courtesy .

OK, you think. But how? We’re a global enterprise with thousands of engineers and operations on every continent. Except maybe Antarctica. No wait, we’re there, too. McMurdo I think. We have software we don’t even know much about, acquired long ago along with the companies that built it. And we’re building new systems or modifying old ones all the time, trying to move everything to the cloud while enhancing data security. Where do we begin to look for the millstones of technical debt?

Have you been in that meeting? If not, can you imagine being in that meeting? Meetings like that are happening around the globe. We’re all in the same soup.

It turns out that the answers to the millstone questions are available, but the pioneers and deep thinkers who have shown the way aren’t working on technical debt. Their field is called systems analysis. They work on problems like the collapse of the North Atlantic fishery, urban deterioration, unemployment, poverty, climate change, and the causes of the Great Recession of 2008—really difficult problems. Although the technical debt problem isn’t quite that challenging, it’s challenging enough to justify taking a look at the methods of systems analysis.

And when we do that, we immediately encounter a concept many call leverage points.

What are leverage points?

Leverage points are places in complex systems where a small change in one thing can produce big changes in system behavior. In a brilliant 1997 article, Donella Meadows describes what she calls “places to intervene in a system.” [Meadows 1997] She followed this article, making improvements each time, in 1999 [Meadows 1999] and 2008 [Meadows 2008]. Let me summarize Meadows’ work here.

To alter the behavior of a complex system, intervene at one or more of 12 categories of leverage points. For example, one category is called “Rules.” It consists of the incentives, punishments, and constraints that govern the behavior of the people and institutions that comprise the system. By adjusting the system’s rules, we can alter overall system behavior.

One more thing: the leverage points form an ordered hierarchy, ordered by effectiveness. Acting at a higher-level leverage point is more effective than acting at a lower-level leverage point. And more difficult, too. The ordering of the categories is a bit fuzzy, because every situation has its own quirks, but generally, the order is as given in the list below.

In a moment I’ll give an example of using leverage point #9, Delays, to bring about change in the way the enterprise deals with technical debt. But first, here’s a brief summary of the leverage points in increasing order of leverage; not enough to truly understand what they are, but probably enough to pique your interest. As I write posts that illustrate interventions at these leverage points, I’ll link to them from here.

  1. Numbers: Constants and parameters such as subsidies, taxes, and standards
  2. Buffers: The sizes of stabilizing stocks relative to their flows
  3. Stock-and-Flow Structures: Physical systems and their nodes of intersection
  4. Delays in feedback loops
  5. Balancing Feedback Loops: The strength of the feedbacks relative to the impacts they are trying to correct
  6. Reinforcing Feedback Loops: The strength of the gain of driving loops
  7. Information Flows:  The structure of who does and does not have access to information
  8. Rules: Incentives, punishments, and constraints
  9. Self-Organization: The power to add, change, or evolve system structure
  10. Goals: The purpose or function of the system
  11. Paradigms: The mind-set out of which the system—its goals, structure, rules, delays, parameters—arises
  12. Transcending Paradigms

Changing systems that have delays in feedback loops

When we use feedback to control systems, and there are delays in the feedback, we can potentially create destructive system behavior. And that can happen when we try to control technical debt.

Whenever we try to control a quantity in an enterprise process, we must (a) set a target value for that quantity; then (b) measure its current value; and then (c) take action as appropriate to move the current value toward the target value. Systems analysts (and control theorists) call that arrangement a feedback loop. The action taken to move the current value to the target value is sometimes called the control signal. Under certain conditions, the feedback works as expected.

For example, to control the profitability of the enterprise, we can examine its net income, say, quarterly. And at the end of each quarter we can make adjustments if net income isn’t in the target range.

Feedback loops generally work pretty well, but under some conditions, oscillations can develop. One of those troublesome situations occurs when there’s a delay in the loop that’s of the same order as (or longer than) the time the system takes to respond to adjustments. Meadows uses the example of adjusting the water temperature of a shower when there’s a long delay between making the adjustment and feeling its effects. Overcorrection is almost inevitable, and that’s what causes system oscillation.

So let’s suppose that we’re trying to control the rate of accumulation of technical debt. One approach is to set a target for TDnew, the new technical debt generated in a project. To be fair to all projects, we decide to normalize this quantity according to the project budget B. So we set targets for each project’s N = TDnew/B, and we require that projects estimate N, on an ongoing basis, with a goal of having N in some target range when the project is complete.

One problem with this approach is that we rarely identify accurately all the technical debt we’ve incurred until some time has passed after project delivery. With time, as the newly produced assets go into production and learning accumulates, we acquire the wisdom needed to identify more of the technical debt we created. This is one source of delay in this feedback loop.

So let’s assume that this happens for several projects, and management decides that delayed recognition of incurred technical debt is a common occurrence. To account for this, management lowers the target ranges for N for future projects. This causes project managers and project sponsors to include in their project plans additional effort directed at retiring more of their incremental technical debt before their projects complete, to enable them to project lower values of N. They must therefore identify as much of the incremental technical debt as they can, and retire it, to meet the lower targets for N.

But recall that technical debt identification sometimes requires time and experience using the newly produced asset. And the reverse process also occurs. Technical artifacts that we thought were technical debt prove to be useful in unexpected ways, and actually turn out not to be debt items after all. As a result, some of the incremental technical debt that got retired before the project was completed actually should not have been retired. Eventually, people realize that this happens with uncomfortable frequency, and so the targets for N are raised once more.

Oscillations thus set in. Long delays inevitably cause them. To prevent oscillations, shorten the delays.

How to shorten delays in feedback controlling technical debt

With technical debt, we can shorten delays in several ways.

  • If the asset is meant for human use, involve representatives of the user population in the development and design process as soon as practical. Have them exercise the asset, or prototypes, early. Listen to their suggestions. Observe how they use the asset.
  • If the asset must interact with non-human assets, exercise it early and often. Don’t think of this as testing, though it might look very much like testing. What you’re actually doing is searching for shortcomings in how the asset interacts with non-human assets, in design and implementation in an asset that already works.
  • Subject the asset to multiple reviews all along the development trajectory. Don’t wait for final release to review it.

These practices expose technical debt items early—potentially, during initial design—thereby reducing delays in identifying what is and what is not technical debt. They help to advance the date at which we uncover missing capabilities or capabilities designed or implemented in awkward ways. No surprise, I’m sure, but these practices are consistent with Agile approaches to technological development.

Indirect effects can add to delayed recognition of technical debt

Most of the argument above assumed that the incremental technical debt associated with the project was incurred within the asset undergoing development or maintenance. But technical debt can occur in other assets as well. When the development team is unaware of such “remote” or “indirect” incremental technical debt, recognition of that new incremental technical debt can be significantly delayed. The project’s N will appear to be smaller that it actually is, until that remote incremental technical debt is recognized.

This form of delay is likely to occur when the debt incurred is asset-exogenous. Recall the example of line extension of mobile phones. In that example, the enterprise incurs technical debt in one set of products as a result of the introduction of a different product. In some cases, the newly incurred technical debt is immediately evident. When it is not, delays can be substantial.

This effect is by no means rare. Any organizational change can potentially add to the technical debt portfolio—reorganizations, acquisitions, expansions, wholly new products, and much more.

Conclusions

Interventions at the leverage points of an organization can produce the changes we want with a minimum of effort. Some subtlety is involved, because Meadows’ leverage points are expressed at a high level of abstraction.  But applying them to the problem of technical debt management is a promising approach.

Bookmark this post. I’ll be linking to more examples of using leverage points to manage technical debt. So far:

References

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

Cited in:

Other posts in this thread

Posted on

Exogenous technical debt

Last updated on July 24th, 2018 at 07:30 pm

Mastering understanding of exogenous technical debt—debt that arises from causes not directly related to the asset that bears the debt—is essential to controlling technical debt formation. Exogenous technical debt is particularly troublesome to those who work on the affected assets. They can’t control its formation, and they’re rarely responsible for creating it. But their internal customers and those who control resources often fail to understand this. Indeed, those who work on the affected assets are often blamed for the formation of exogenous technical debt even though they had no role in its formation, and could have done nothing to prevent its formation.

Asbestos with muscovite.
Asbestos with muscovite. Asbestos is a family of six minerals that occur naturally in fibrous form. The fibers are all known carcinogens. Until 1990, it was widely used in many common building materials, including insulation, plaster, and drywall joint compound. It is now banned, but it’s present in many existing structures, including homes and offices. The installation of the ban caused these structures to incur exogenous technical debt. Photo by Aramgutang courtesy Wikipedia.

Technical debt is exogenous when it’s brought about by an activity not directly related to the assets in which the debt appears. The word exogenous comes from the Greek exo– (outside) + –genous (related to producing). So exogenous technical debt is that portion of an asset’s debt that comes about from activities or decisions that don’t involve the asset directly.

Because so much technical debt is produced indirectly, controlling its direct formation—for example, by engineering teams—isn’t sufficient for achieving enterprise control of technical debt formation. To control technical debt formation, we must track which activities produce it, including both direct and indirect effects. Allocating technical debt retirement costs to the activities that brought that debt about, even if the allocation doesn’t affect budget authority for those activities, is therefore a useful practice. Knowledge about which past activities created technical debt, and how much, is helpful for long-term reduction in the rate of technical debt formation.

When we think of technical debt, we tend to think of activities that produce it relatively directly. We often imagine it as resulting solely from engineering activity, or from decisions not to undertake engineering activity. In either case the activity involved, whether undertaken or not, is activity directly involving the asset that carries—or will be carrying—the technical debt. This kind of technical debt is endogenous technical debt. The word endogenous comes from the Greek endo– (within or inside) + –genous (related to producing).  So endogenous technical debt is that portion of an asset’s debt that comes about from activities or decisions that directly involve the asset.

More about endogenous technical debt in future posts. For now, let’s look more closely at exogenous technical debt, and its policy implications.

Examples of exogenous technical debt

In “Spontaneous generation,” I examined one scenario in which technical debt formation occurs spontaneously—that is, in the absence of engineering activity. Specifically, I noted how the emergence of the HTML5 standard led to the formation of technical debt in some (if not all) existing Web sites, in the sense that they didn’t exploit capabilities that had become available in HTML5. Moreover, some sites whose developers had elected to emulate capabilities of the new standard by exploiting alternative technologies needed rehabilitation to remove the emulation and replace it with use of facilities in the HTML5 standard. All of these artifacts—including those that existed, and those that didn’t—comprised technical debt. This scenario thus led to the formation of exogenous technical debt.

In a second example, AMUFC, A Made-Up Fictitious Corporation, incurs technical debt when the vendor that supplies the operating system (OS) for AMUFC’s desktop computers announces the date of the end of extended support for the version of the OS in use at AMUFC. Because the end of extended support brings an end to security updates, AMUFC must retire that debt by migrating to the next version of that vendor’s OS before extended support actually ends.

In both of these examples, the forces that lead to formation of exogenous technical debt are external to both the enterprise and the enterprise’s assets. But what makes technical debt exogenous is that the forces that led to its formation are unrelated to any of the engineering work being performed on the asset that carries the debt. This restriction is loose enough to also include technical debt that arises from any change or activity external to the asset, but within the enterprise.

Exogenous technical debt arising from actions within the enterprise

Exogenous technical debt can arise from activities or decisions that take place entirely within the enterprise.

For example, consider a line of mobile devices developed and marketed by AMUFC (A Made-Up Fictitious Corporation). Until this past year, AMUFC has been developing ever more capable devices, thereby extending its line of offerings at the high end—the more expensive and capable members of the line. But this past quarter, AMUFC developed a low-end member of the line, and as often happens, price constraints led to innovations that could produce considerable savings in manufacturing costs if those innovations were applied to all members of the line. In effect, then, the designs of the previously developed models in this line of devices have incurred exogenous technical debt. The debt is exogenous because the activity that led to debt formation was not performed on the assets that now carry the debt, even though the activity that led to debt formation occurred within the enterprise. This kind of exogenous technical debt might be termed asset-exogenous. Exogenous technical debt of the kind that’s incurred by activity beyond the enterprise might be termed enterprise-exogenous.

Exogeneity versus endogeneity

For asset-exogenous technical debt, ambiguity between endogeneity and exogeneity can arise. The example above regarding the line of mobile devices produced by AMUFC provides an illustration.

For convenience, call the team that developed one of the high-end devices Team High. Call the team that developed the low-end device Team Low. From the perspective of Team High, the technical debt due to the innovations discovered by Team Low is exogenous. But from the perspective of the VP Mobile Devices, that same technical debt might be regarded as endogenous. The debt can be endogenous at VP level because it’s possible to regard the entire product line as a single asset, and that might actually be the preferred perspective of VP Mobile Devices.

Exogeneity and legacy technical debt

The technical debt portfolio of a given asset can contain a mix a technical debt that arose from various past incidents. In assessing the condition of the asset, it’s useful to distinguish this existing debt from debt that’s incurred as a consequence of any current activity or decisions. Call this pre-existing technical debt legacy technical debt.

The legacy technical debt carried by an asset is technical debt associated with that asset, and which exists in that asset 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, workers discover 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, increase the property value, and reduce the cost of eventual demolition. In this situation asbestos removal amounts to retirement of legacy technical debt, and accounting for it as part of the common-area renovation would be misleading.

When contemplating efforts to retire legacy technical debt, exogeneity becomes a factor in allocating the necessary resources. If the debt in question is enterprise-exogenous, then we can justifiably budget the effort from enterprise-level accounts if appropriate. For other cases, other pools of resources become relevant depending on what actions created the debt. For example, if the exogenous technical debt arose because of a departmental change in standards, debt retirement costs can justifiably be allocated to the standards effort. If the exogenous technical debt arose from innovations in other members of the asset’s product line, those debt retirement costs can justifiably be allocated to the product line.

Policy insights

Understanding the properties of exogenous technical debt can be a foundation for policy innovations that enhance enterprise agility.

Culture transformation

Widespread understanding the distinction between exogenous and endogenous technical debt is helpful in controlling blaming behavior that targets the engineering teams responsible for developing and maintaining technological assets.

Understanding of asset-exogenous technical debt helps non-engineers understand how their actions and decisions can lead to technical debt formation, even when there is no apparent direct connection between those actions or decisions and the assets in question.

Resource allocation

Data about the technical debt creation effects of enterprise activities is helpful in allocating technical debt retirement costs. For example, when we know all the implications of reorganization, including its impact on internal data about the enterprise itself, we can charge data-related activity to the reorganization instead of to general accounts of the Information Technology function. This helps the enterprise understand the true costs of reorganization.

Similarly, data about enterprise-exogenous technical debt helps planners understand how to deploy resources to gather external intelligence about trends that can affect internal assets. Such data is also useful for setting levels of support and participation in industrial standards organizations or in lobbying government officials.

Knowing the formation history of exogenous technical debt provides useful guidance for those charged with allocating the costs of retiring technical debt or preventing its formation.

References

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

Cited in:

Other posts in this thread

Posted on

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

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

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:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

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

Posted on

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

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

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:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

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

Posted on

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

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

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:

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

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

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

Posted on

The Dunning-Kruger effect can lead to technical debt

Last updated on May 31st, 2018 at 07:43 am

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

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

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] Justin Kruger and David 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:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

Cited in:

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

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

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

Posted on

The concept of MICs

Last updated on July 2nd, 2018 at 02:35 pm

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, 10:3, March 23, 2012.

Available: here; Retrieved: March 16, 2017

Also cited in:

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

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] Justin Kruger and David 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:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

Cited in:

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

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

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

  • The Principal Principle: Focus on MICs
    The Principal Principle is that a focus on the metaphorical principal of a technical debt can be your undoing. Focus on the metaphorical interest charges. Drive them to Zero and keep them there.
  • Where the misunderstandings about MICs come from
    Misunderstandings about the metaphorical interest charges on technical debt are costly. They prevent us from exploiting the properties of technical debt that reduce carrying costs and retirement costs. And the misunderstandings arise from the fact that the technical debt metaphor is only a metaphor—technical debt and financial debt are different.
  • MICs can change when other debts are retired
    The metaphorical interest charges (MICs) and metaphorical principal (MPrin) of a particular class of technical debt can change as a result of retiring other seemingly unrelated classes of technical debt. In most cases, engineering expertise is required to determine technical debt retirement strategies that can exploit this property of technical debt.
  • MICs on technical debt can be difficult to measure
    Unlike financial debt, for technical debt there are no legally required reports or disclosures. We can sometimes estimate MICs, but most organizations don’t track the data necessary to estimate MICs with useful precision. Indeed, developing useful estimates is often technically impossible.
  • MICs can sometimes be deferred or advanced without penalty
    Rescheduling interest payments on financial debt is possible only by prearrangement or in bankruptcy, but MICs on technical debt can often be rescheduled by rescheduling work that might incur them. This is useful when we plan to retire assets bearing technical debt, because their technical debt vanishes.
  • How financial interest charges differ from interest charges on technical debt
    The common understanding of interest on financial debts doesn’t correspond to the reality of technology-based systems, which are the targets of the technical debt metaphor. Formulating sound technical debt policy depends on understanding the nature of the difference between interest on financial debt and the metaphorical interest charges associated with technical debt.
Posted on

Glossary and Terminology

Last updated on October 8th, 2019 at 07:27 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.

Asset-exogenous technical debt

Exogenous technical debt is asset-exogenous when it’s brought about by an activity external to an asset, but internal to the enterprise. For example, a change in standards or regulations by some body within the enterprise can cause an asset to incur an asset-exogenous technical debt.

ATD

See Auxiliary technical debt.

Auxiliary technical debt

In the context of a Technical Debt Retirement Project (DRP) that has as an objective retiring from a specified set of assets a particular kind or particular kinds of technical debt, the ATD is the collection of instances of any other kinds of technical debt other than the kind that the DRP is trying to retire. More: “Rules of engagement for auxiliary technical debt”

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.

Confirmation bias

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

Debt contagion

If a class of technical debt is allowed to remain outstanding, its volume can increase as a consequence of seemingly unrelated actions or decisions. Moreover, its existence can cause increases in the volume of other existing classes of technical debt, and its existence can lead to the formation of new classes of technical debt. This process is called debt contagion. More: “How technical debt can create more technical debt”

DRP

In this blog, I use the term DRP to mean a (technical) Debt Retirement Project. A DRP is a project that has as an objective retiring from a specified set of assets a particular kind of technical debt (or particular kinds of technical debt). Many projects have objectives of debt retirement, at some point or other. But DRPs differ from most, in that debt retirement is their primary objective—indeed, it might be their sole objective. More: “Nine indicators of wickedness”

Echo release

An echo release of an asset is a release version whose primary purpose is technical debt retirement. Typically, it’s created immediately following a release version that has created some incremental technical debt, hence the term “echo release.” The echo release is then executed to retire that incremental technical debt, and not to repair defects or add capability. More: “Accounting for technical debt”

Endogenous technical debt

When we think of technical debt, we tend to think of activities that produce it relatively directly. We often imagine it as resulting solely from engineering activity, or from decisions not to undertake engineering activity. In either case the activity involved, whether undertaken or not, is activity directly involving the asset that carries the technical debt. This kind of technical debt is endogenous technical debt. The word endogenous comes from the Greek endo– (within or inside) + –genous (related to producing).  So endogenous technical debt is that portion of an asset’s debt that comes about from activity or decisions that directly involve the asset. More: “Exogenous technical debt”

Enterprise-exogenous technical debt

Exogenous technical debt is enterprise-exogenous when it’s brought about by an activity external to the enterprise. For example, a change in standards or regulations by some body outside the enterprise can cause an asset to incur an enterprise-exogenous technical debt.

Exogenous technical debt

Technical debt is exogenous when it’s brought about by an activity not directly related to the assets in which the debt appears. The word exogenous comes from the Greek exo– (outside) + –genous (related to producing). So exogenous technical debt is that portion of an asset’s debt that comes about from activity or decisions that don’t involve the asset directly. More: “Exogenous technical debt”

Ill-structured problem

An ill-structured problem is a problem that isn’t a well-structured problem [Simon 1973]. An example of an ill-structured problem is finding a definition for ill-structured problems. Another: designing a computer programming language. Still another, even more to the point: deciding when to retire a particular class of technical debt. NDM is more likely to be successful with ill-structured problems than is RDM.

Incremental technical debt

Incremental technical debt is either newly incurred exogenous technical debt, or 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. More: “Controlling incremental technical debt”

Instance of technical debt

See “Class of technical debt”

Intertemporal choice

Confronted with advice from technical experts regarding the urgent need to address the burden of enterprise technical debt, decision makers must consider an unpleasant possibility. To make resources available to retire the technical debt, it might be necessary to temporarily defer investment in some new products or enhancing some existing products. And if they make the recommended investments in technical debt retirement, customers won’t benefit in any visible way. So the choice reduces to one between new products and enhancements relatively sooner, versus retiring technical debt and only later attending to new products and enhancements of existing products. This dilemma is an example of what behavioral economists call intertemporal choice [Loewenstein 1992].

Key Performance Indicator (KPI)

A Key Performance Indicator (KPI) is a metric that provides meaningful insight that’s used to guide business decisions. All KPIs are metrics; not all metrics are KPIs. More: “Metrics for technical debt management: the basics”

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. More: “Exogenous technical debt”

Localizable technical debt

Localizable technical debt is technical debt that manifests itself as discrete chunks. Each instance is self-contained, and we can “point” to it as an instance of the debt in question. For example, if the organization regards Windows 10 as the current operating system for personal computers, and early versions of Windows as technical debt, the each computer that runs and earlier version of Windows is an instance of that technical debt. Each instance is discrete and localized. More: “Retiring localizable technical debt”

Measure

A measure is the result of determining the value of a quantifier. For example, we might use the quantifier’s definition to determine a measure of how much human effort has been expended on an asset in the past fiscal quarter. More: “Metrics for technical debt management: the basics”

Metric

A metric is an arithmetic formula expressed in terms of constants and a set of measures. One of the simpler metrics consists of a single ratio of two measures. For example, the metric that captures the average cost of acquiring a new customer in the previous fiscal quarter is the ratio of two measures, namely, the investment made in acquiring new customers, and the number of new customers acquired. More: “Metrics for technical debt management: the basics”

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”

Naturalistic decision-making

Naturalistic decision-making (NDM) entails situation assessment and evaluation of a single option to select a satisfactory option. [Zannier 2007] Features that define naturalistic decision-making are “time pressure, high stakes, experienced decision makers, inadequate information (information that is missing, ambiguous, or erroneous), ill-defined goals, poorly defined procedures, cue learning, context (e.g., higher-level goals, stress), dynamic conditions, and team coordination.”  [Klein 2017]

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 1977] [Kahneman 1979]. 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?”

Quantifier

A quantifier is a specification for a measurement process designed to yield a numeric representation of some attribute of an asset or process. Quantifiers are used to obtain the values called measures, which in turn are used in computing metrics. More: “Metrics for technical debt management: the basics”

Rational decision-making

Rational decision-making (RDM) is an approach to making a choice of an option from among a set of options by selecting the option that is optimal with respect to a set of quantitative criteria. [Zannier 2007] Rational choice strategies generally follow this framework: (1) Identify a set of options; (2) Identify criteria for evaluating them; (3) Assign weight to each evaluation criterion; (4) Rate the options relative to the criteria; (5) Choose the option with the highest score. Many different frameworks for implementing this strategy are available, some specialized to specific subject domains [Thokala 2016].

Refactoring

Fowler defines refactoring as “the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure” [Fowler 1999]. Although refactoring is a term specific to software development processes, the concept applies to all technological development. For example, an automobile manufacturer’s decision to alter the design of one of their model vehicles to reduce manufacturing costs can be viewed as a form of refactoring. Refactoring is a practice essential to effective technical debt management. More: “Refactoring for policymakers”

Regression testing

Regression testing is a testing regimen that ensures that a previously developed and tested system still performs the same way after it has been altered or when it’s used in a new context. Regression testing is essential when we alter a system by retiring some of its technical debt.

The reification error

The reification error (also called the reification fallacy, concretism, or the fallacy of misplaced concreteness) is an error of reasoning in which we treat an abstraction as if it were a real, concrete, physical thing. Reification is useful in some applications, such as object-oriented programming and design. But when we use it in the domain of logical reasoning, troubles can arise. Specifically, we can encounter trouble when we think of “measuring” technical debt. Strictly speaking, we cannot measure technical debt. We can estimate the cost of retiring it, but estimates are only approximations. And in the case of technical debt, the approximations are usually fairly rough. To regard these estimates as measurements is to risk reifying them. Then when the actual cost of a debt retirement project is dramatically larger than the estimate, the consequences for enterprise budgets can be severe. We must always regard “measurements” of technical debt as estimates—estimates that are so prone to error that we must plan for error.  The reification error is the dual of the resilience error. More: “Metrics for technical debt management: the basics.”

The resilience error

If the reification error is an error of reasoning in which we treat an abstraction as if it were a real, concrete, physical thing, the resilience erroris an error of reasoning in which we treat an abstraction as if it were more flexible, resilient, and adaptable than it actually is. When we commit the resilience error with respect to an abstraction, we adopt the belief—usually without justification, and possibly outside our awareness—that if we make changes in the abstraction without fully investigating the consequences of those changes, we can be certain that the familiar properties of the abstraction we modified will apply, suitably modified, to the new form of the abstraction.  Or we assume incorrectly that the abstraction will accommodate any changes we make to its environment. The resilience error is the dual of the reification error. We are at risk of making the resilience error when we refactor assets to reduce their burden of technical debt. More: “The resilience error and technical debt.”

Secured technical debt

A secured technical debt, like a secured financial debt, is one for which the enterprise has reserved the resources needed to retire the debt. However, unlike a financial debt, the resources required to retire a technical debt might not be purely financial. They might include particular staff, equipment, test beds, downtime, and financial resources. The commitment might extend beyond the current fiscal period. Secured technical debt is a powerful means of driving down total technical debt burden, but it might require modification of internal budget management processes and fiscal reporting. Policymakers can help in designing and deploying the necessary changes. More: “Using SMART goals for technical debt reduction”

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”

Super wicked problem

A subset of wicked problems can be viewed as super wicked [Levin 2012]. Levin, et al. list the following four properties of super wicked problems: (1) Time is running out; (2) Those who cause the problem also seek to provide a solution or influence the solution; (3) The central authority needed to address the problem is weak, non-existent, or chooses not to act effectively; (4) Policy responses discount the future irrationally. I’ve come to believe that some technical debt retirement project design can be a super wicked problem. More: “Retiring technical debt can be a super wicked problem”

Taylorism

Taylorism is an approach to management developed by Frederick Winslow Taylor in the early part of the twentieth century [Taylor 1913] [Kanigel 1997]. He proposed three principles of scientific management could produce maximum efficiency: (1) scientific selection of the person performing the work; (2) scientific breakdown of tasks; and (3) separating planning from execution. These principles are the basis of what became known in software engineering as the waterfall lifecycle. The approach works well for well-structured problems, but does not work well at all for ill-structured problems. Moreover, it depends for success on repeating solutions to problems already solved, which is why it proved so valuable in early manufacturing. Its unsuitability for ill-structured problems is an important part of the basis for the Agile approach to problem solving.

TDIQ

In the context of a Technical Debt Retirement Project (DRP) that has as an objective retiring from a specified set of assets a particular kind of technical debt (or particular kinds of technical debt), the TDIQ is the Technical Debt In Question. More: “Retiring technical debt in irreplaceable assets”

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”

Temporal discounting

Temporal discounting is the human tendency to give greater value to a reward (or as economists would say, to assign greater utility to a good) the earlier it arrives. An analogous process affects perceptions of inconvenience or disutility: people assign more negative values to penalties and inconveniences the sooner they arrive. If the discount rate is constant, the discounting is termed exponential discounting or rational discounting. But other forms are possible. Hyperbolic discounting is one form of discounting at a rate that is higher for near-term arrivals than for distant-term arrivals [Laibson 1997]. Humans have been observed experimentally to favor a form of temporal discounting that is well modeled as hyperbolic discounting.

Terrifying opportunity

A terrifying opportunity arises when the organization rejects (or fails to recognize) a market opportunity because exploiting it would involve modifying an existing asset or product offering that harbors a heavy load of technical debt. The debt causes decision-makers to assess that the probability of success is so low that the opportunity seems terrifying, and they therefore reject the opportunity. More: “MICs on technical debt can be difficult to measure”

Well-structured problem

As defined by Simon [Simon 1973], a well-structured problem is a problem that has some or all of six characteristics. The first is the existence of a definite criterion for testing any proposed solution, and a mechanizable process for applying that criterion. Second, there is at least one problem space in which we can represent the initial problem state, the goal state, and all states that can be reached or considered while solving the problem. There are four more criteria, but these are the biggies. An example of a well-structured problem is the game of chess. RDM is useful for attacking well-structured problems.

Wicked problem

A problem is a wicked problem if it meets the ten criteria established by Rittel and Webber [Rittel 1973]. Four of the criteria: it’s an ill-structured problem; it’s incompletely defined or internally contradictory; its solutions are not true-or-false, but good-or-bad; and there’s no way to exhaustively describe all solutions. I’m convinced that technical debt retirement project design can be a wicked problem. More: “Self-sustaining technical knowledge deficits during contract negotiations.”

References

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

Available: here; Retrieved: March 16, 2017

Also cited in:

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

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 1977] Daniel Kahneman and Amos Tversky. “Intuitive Prediction: Biases and Corrective Procedures,” Technical Report PTR-1042-7746, Defense Advanced Research Projects Agency, June 1977.

Available: here; Retrieved: September 19, 2017

Cited in:

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

Cited in:

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

Order from Amazon

Cited in:

[Kanigel 1997] Robert Kanigel. The one best way: Frederick Winslow Taylor and the enigma of efficiency. Viking Penguin, 1997.

Order from Amazon

Cited in:

[Klein 2017] Gary Klein. Sources of Power: How People Make Decisions, 20th Anniversary Edition. Cambridge, Massachusetts: The MIT Press, 1999.

Order from Amazon

Cited in:

[Kruger 1999] Justin Kruger and David 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:

[Laibson 1997] David Laibson. “Golden eggs and hyperbolic discounting,” Quarterly Journal of Economics 112:2, 1997, 443-477.

Available: here; Retrieved: October 25, 2018

Cited in:

[Levin 2012] Kelly Levin, Benjamin Cashore, Steven Bernstein, and Graeme Auld. “Overcoming the tragedy of super wicked problems: constraining our future selves to ameliorate global climate change,” Policy Science 45, 2012, 123–152.

Available: here; Retrieved: October 17, 2018

Cited in:

[Loewenstein 1992] George Loewenstein and Drazen Prelec. “Anomalies in Intertemporal Choice: Evidence and an Interpretation,” Quarterly Journal of Economics, 57:2, 1992, 573-598.

Available: here; Retrieved: October 12, 2018

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:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Simon 1973] Herbert A. Simon. “The Structure of Ill Structured Problems,” Artificial Intelligence 4, 1973, 181-201.

Available: here; Retrieved: 10/16/18

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

Cited in:

[Taylor 1913] Frederick Winslow Taylor. The Principles of Scientific Management. New York: Harper & Brothers, 1913.

Available: here; Retrieved: October 16, 2018 Order from Amazon

Cited in:

[Thokala 2016] Praveen Thokala, Nancy Devlin, Kevin Marsh, Rob Baltussen, Meindert Boysen, Zoltan Kalo, Thomas Longrenn et al. “Multiple Criteria Decision Analysis for Health Care Decision Making—An Introduction: Report 1 of the ISPOR MCDA Emerging Good Practices Task Force,” Value in Health 19:1, 2016, 1-13.

Available: here; Retrieved: 10/16/18

Cited in:

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

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

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:

[Zannier 2007] Carmen Zannier, Mike Chiasson, and Frank Maurer. “A model of design decision making based on empirical results of interviews with software designers,” Information and Software Technology 49, 2007, 637-653.

Available: here; Retrieved October 15, 2018

Cited in:
Posted on

Technical debt in software engineering

Ward Cunningham, who coined the technical debt metaphor

Last updated on December 24th, 2018 at 01:37 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, 10:3, March 23, 2012.

Available: here; Retrieved: March 16, 2017

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

[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.

Available: here; Retrieved: August 23, 2019

Cited in:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

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 1977] Daniel Kahneman and Amos Tversky. “Intuitive Prediction: Biases and Corrective Procedures,” Technical Report PTR-1042-7746, Defense Advanced Research Projects Agency, June 1977.

Available: here; Retrieved: September 19, 2017

Cited in:

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

Cited in:

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

Order from Amazon

Cited in:

[Kanigel 1997] Robert Kanigel. The one best way: Frederick Winslow Taylor and the enigma of efficiency. Viking Penguin, 1997.

Order from Amazon

Cited in:

[Klein 2017] Gary Klein. Sources of Power: How People Make Decisions, 20th Anniversary Edition. Cambridge, Massachusetts: The MIT Press, 1999.

Order from Amazon

Cited in:

[Kruger 1999] Justin Kruger and David 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:

[Laibson 1997] David Laibson. “Golden eggs and hyperbolic discounting,” Quarterly Journal of Economics 112:2, 1997, 443-477.

Available: here; Retrieved: October 25, 2018

Cited in:

[Levin 2012] Kelly Levin, Benjamin Cashore, Steven Bernstein, and Graeme Auld. “Overcoming the tragedy of super wicked problems: constraining our future selves to ameliorate global climate change,” Policy Science 45, 2012, 123–152.

Available: here; Retrieved: October 17, 2018

Cited in:

[Loewenstein 1992] George Loewenstein and Drazen Prelec. “Anomalies in Intertemporal Choice: Evidence and an Interpretation,” Quarterly Journal of Economics, 57:2, 1992, 573-598.

Available: here; Retrieved: October 12, 2018

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:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.

Available: here; Retrieved: August 22, 2019

Cited in:

[Simon 1973] Herbert A. Simon. “The Structure of Ill Structured Problems,” Artificial Intelligence 4, 1973, 181-201.

Available: here; Retrieved: 10/16/18

Cited in:

[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.

Available: here; Retrieved: August 22, 2019

Cited in:

[Taylor 1913] Frederick Winslow Taylor. The Principles of Scientific Management. New York: Harper & Brothers, 1913.

Available: here; Retrieved: October 16, 2018 Order from Amazon

Cited in:

[Thokala 2016] Praveen Thokala, Nancy Devlin, Kevin Marsh, Rob Baltussen, Meindert Boysen, Zoltan Kalo, Thomas Longrenn et al. “Multiple Criteria Decision Analysis for Health Care Decision Making—An Introduction: Report 1 of the ISPOR MCDA Emerging Good Practices Task Force,” Value in Health 19:1, 2016, 1-13.

Available: here; Retrieved: 10/16/18

Cited in:

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

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

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:

[Zannier 2007] Carmen Zannier, Mike Chiasson, and Frank Maurer. “A model of design decision making based on empirical results of interviews with software designers,” Information and Software Technology 49, 2007, 637-653.

Available: here; Retrieved October 15, 2018

Cited in:
Show Buttons
Hide Buttons
%d bloggers like this: