The structure of metaphors

Last updated on December 17th, 2017 at 05:15 pm

A metaphor is a figure of speech that references one concept, object, or action, by identifying it with another, when that identification is not literally accurate. Metaphors help us understand and experience one thing, with which we might be unfamiliar, in terms of another, with which we are more familiar [Lakoff 1980].

A squirrel

For example, “my son’s room is a war zone,” identifies my son’s room as a war zone, when it is not literally a war zone. We mean by this that his room might be messy and disorganized, but we do not mean to imply that military ordnance or troops are involved. More examples:

  • True friends stab you in the front. — Oscar Wilde
  • A squirrel is just a rat in a cuter outfit. — “Carrie Bradshaw,” played by Sarah Jessica Parker in Sex in the City
  • A bank is a place where they lend you an umbrella in fair weather and ask for it back when it begins to rain. — variously attributed to Robert Frost, Mark Twain, and others

In these examples, Oscar Wilde is not saying that friends actually stab anyone; “Carrie Bradshaw” is not saying that squirrels are rats, or that they wear clothing; and Frost or Twain are not saying that banks actually lend umbrellas. Nevertheless these three statements do literally imply stabbings, squirrel clothing, and umbrella distribution. These metaphors make their points by being literally inaccurate. The literal but untrue assertion is the hallmark of the metaphor.

The fundamental structure of metaphors is “A is B.” Borrowing terminology from cognitive linguistics, A, the main entity referenced, is called the target of the metaphor; B, the entity alluded to, is called the source. Thus, the squirrel is the target; the rat in a cuter outfit is the source. The bank is the target; the perfidious umbrella lender is the source. For the technical debt metaphor, the needed technical work is the target; financial obligation or financial debt is the source. Metaphors serve to aid us in applying what we understand well in the domain of the source, to what we understand less well in the domain of the target.

DefinitionA metaphor is a figure of speech used to convey understanding of one concept, object, or action by identifying it with another that is well understood, even though the identification is not literally accurate. The well-understood concept is called the source. The less-well-understood concept is called the target. The metaphor is thus a statement that “<Target> is <Source>.” Although the identification of target with source is literally invalid, it provides a means of understanding some aspects of the target in terms of some of the properties or behavior of the source.

Because metaphors compel our minds to accept the identification between source and target in toto, they can cause us to make errors of thought. Those errors create risks for the enterprise as we attempt to manage technical debt. The risk arises because we begin to regard technical debt as a form of financial debt, when in reality it is not. This misidentification is an acceptable risk, if it is properly managed and understood, but that risk is often unrecognized, and therefore it remains unmitigated. A significant source of this risk is our inability to control which attributes of the metaphor’s source the reader or listener chooses to associate with the metaphor’s target. We can call this phenomenon unintended association.

Some of the unintended associations of the technical debt metaphor cause real problems for organizations as they try to manage their technical debt. We explore the unintended associations of the technical debt metaphor next time.

References

[Lakoff 1980] George Lakoff and Mark Johnson. Metaphors We Live By. Chicago: The University of Chicago Press, 1980.

The classic and fundamental study of metaphor. Order from Amazon

Cited in:

Related posts

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

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

Available: here; Retrieved: March 10, 2017.

Cited in:

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

Cited in:

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

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Lakoff 1980] George Lakoff and Mark Johnson. Metaphors We Live By. Chicago: The University of Chicago Press, 1980.

The classic and fundamental study of metaphor. Order from Amazon

Cited in:

Technical Debt: So What?

Last updated on November 24th, 2017 at 06:59 pm

This post is for readers who are skeptical that technical debt is much of a problem, or who might be thinking that it’s just the latest buzzword the engineers have cooked up to justify bigger budgets or late deliveries.

Of course I have no knowledge of your specific situation, but technical debt is a real thing, it probably affects your organization, and skepticism, though usually healthy, is unwise when it comes to technical debt. Here’s the short version:

If you produce or use technology in your organization, you’re probably carrying technical debt, it’s costing you real money, it’s slowing you down, and unless you address it, it will increase, and eventually take you out of the game.

A knight’s armor
A knight’s armor. To this day, in the United Kingdom, a law entitled ‘Statute Forbidding Bearing of Armour (1313)’ remains in effect. As bodies of legislation grow and evolve, they develop inconsistencies, and outmoded laws accumulate. They are the legislative equivalent of technical debt.

Technical debt makes systems more difficult to maintain, less cybersecure, more difficult to enhance, more expensive to operate, and less effective in achieving organizational objectives. Although there is some disagreement about the definition of technical debt, there is broad agreement that the problem is growing rapidly [Fowler 2003]. If current trends continue, or accelerate, someday soon many of our technology-based assets will become unmaintainable and cyber-indefensible. The people, enterprises, and governments that depend on those assets will be unable to adapt rapidly enough to changing markets, changing technologies, changing cyber-threats, and changing customer needs. If we are ever to gain effective control of technical debt, we must change organizational technology management policy.

Technical debt afflicts organizations of all sizes. The really big problems — the ones that sometimes make the news — tend to belong to big corporations. For example, Google’s code base of “hundreds of millions” of lines of code once contained dependencies among its modules that were ungoverned (and ungovernable) [Morgenthaler 2012]. The sheer number of dependencies and the frequency of changes so slowed the development process that it affected Google’s operations. They dealt with this form of technical debt with three strategies: exploit automation, make it easy to do the right thing, and make it hard to do the wrong thing.

But small companies are also affected. Consider the fictitious company Alpha Properties LLC, which manages small condominium associations (fewer than 100 units). They provide excellent value to small clients by exploiting automation to keep their own operating expenses low. Many of their automation assets are implemented as Microsoft Excel macros. When Microsoft released Excel 2013, Alpha’s macros would have been affected, and they elected to incur technical debt by remaining in Excel 2010. However, mainstream support for Excel 2010 ended in October 2015, with extended support scheduled to end in October 2020. Alpha realizes that they must retire this debt well before that, but finding the resources to do it has been a challenge.

For non-engineers, and specifically for policymakers, what exactly is the technical debt problem? It’s a problem that afflicts complex technological assets, where a technological system is almost anything humans can construct, including highways, bridges, computers, satellites, software — anything. And that includes a class of assets that have no physical manifestation, such as software, surgical procedures, and legislation. All these assets have associated bodies of knowledge, both of which evolve. When they do evolve, technical debt can arise, and it can reside in the asset, in its associated body of knowledge, in the assets we use to interact with the asset, or all three.

We’re dealing with the consequences of the technical debt problem when we’re aware of structures within or around an existing asset that can be improved, but those improvements have been deferred. Subsequently, we find that making a change to an existing asset is so complicated and such a delicate matter that only a few experts can undertake the effort successfully. When they do, the cost of the effort is difficult to predict with useful precision, and there’s a significant probability of their failing multiple times before they finally succeed — if they ever do succeed. When we include all cost sources, costs can be high enough to rival or exceed the initial development cost of the asset, even when the changes in question seem relatively small.

Briefly, the technical debt problem is that as technological assets evolve, they can become increasingly difficult to maintain, defend, enhance, or extend. The difficulty can become so great that many owners of technological assets choose to begin anew rather than continue to operate the assets they have.

References

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

Available: here; Retrieved: March 10, 2017.

Cited in:

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

Cited in:

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

Cited in:

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

[Lakoff 1980] George Lakoff and Mark Johnson. Metaphors We Live By. Chicago: The University of Chicago Press, 1980.

The classic and fundamental study of metaphor. Order from Amazon

Cited in:

[Morgenthaler 2012] J. David Morgenthaler, Misha Gridnev, Raluca Sauciuc, and Sanjay Bhansali. “Searching for Build Debt: Experiences Managing Technical Debt at Google,” Proceedings of the Third International Workshop on Managing Technical Debt (MTD 2012), Piscataway, NJ: IEEE Press, 2012, 1-6.

Available: here; Retrieved: November 11, 2017

Cited in:
Show Buttons
Hide Buttons