How MPrin can change spontaneously

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

SummaryThe MPrin of technical debt left in place can increase or decrease, even if the artifacts that comprise the technical debt don’t change. This variability can be exploited to advantage in some rare cases. Most often, though, the MPrin increases with time. That’s why it’s risky to leave a technical debt in place under the assumption that its MPrin is fixed.

Recall that our definition of the metaphorical principal of a technical debt at a given time is the cost of retiring the debt at that time. This cost can change with time. For example, due to subsequent maintenance and enhancements, the part of the asset in which the debt is embedded might become rather more complicated or constrained than it was earlier, even if the elements that comprise the debt itself have remained unchanged. Moreover, any extensions to the asset in question, or to other assets, that use services provided by subsystem manifesting the debt might also require alteration at debt retirement time. Untangling the debt from its surroundings, making necessary modifications, and testing the result, can be a delicate and complex process that actually costs more at debt retirement time than whatever was saved when the debt was incurred.

On the other hand, in some circumstances, the cost of retiring the debt can decrease over time. Consider the following fictitious example.

A high pressure sodium streetlight at dusk
A high pressure sodium streetlight at dusk. Photo (cc) Famartin courtesy Wikimedia Commons.

Zion is a small city of 110,000 that’s struggling with two problems related to street lighting. Its current streetlights use High-Pressure Sodium (HPS) lights, which use almost twice as much energy as do the newer LED streetlights for the same level of illumination. Zion’s second problem is that the existing streetlights provide only one level of illumination throughout the city. This is causing a stream of complaints from many residents who have concerns about street lighting spilling onto their property at night. The bright light interferes with the sleep patterns of people and their pets.

Because both of these problems have technical solutions that became available after the current HPS lights were installed, they can be viewed as arising from technical debt. Zion had investigated resolving the light pollution problem, but could not find a solution it could afford. Time passed. When LED street lights became widely available, Zion investigated retiring its HPS lights, and found an LED lighting system that was dimmable on a block-by-block basis using a wireless control system. By retiring the technical debt associated with the HPS lights, Zion was able to afford retiring the technical debt associated with its one-size-fits-all un-dimmable lighting system.

Zion was able to afford to retire both forms of technical debt at once because of the way they interacted, even though retiring them one at a time would have been too expensive.

This example shows that the MPrin of a technical debt can vary widely, depending on the assets involved, and on what other debts they carry. Such variation is far more common in the realm of technical debt than it is in the world of financial debt.

Related posts

The metaphorical principal of a technical debt

Last updated on November 21st, 2017 at 09:05 am

The “principal” amount of a technical debt is not like the principal amount of a financial debt. In fact, the two are so different that policymakers can make real trouble for their organizations if they fail to take the differences into account.

Accomac Debtors’ Prison in Accomac, Virginia
Accomac Debtors’ Prison in Accomac, Virginia. Built in 1783 as a jailer’s house, it served as a debtors’ prison from 1824 to 1849. Debtors imprisoned there were required to work to earn their keep and to retire their debt, if they could not find other means to do so. Today, bankruptcy laws facilitate seizure of property to retire debts, a much more enlightened approach. Requiring the product or service engineering functions to fund technical debt retirement efforts through expense budgets is analogous to debtors’ prison. A more enlightened approach is needed.  Photo (cc) Ser Amantio di Nicolao, courtesy Wikimedia Commons.

In the field of finance, the principal amount of a loan at the time of origination is the amount that was borrowed. Over time, as the debtor makes payments according to the terms of typical loan agreements, the principal either remains constant, in which case it’s repaid in a lump sum at a specified date, or it declines gradually, in increments, with each payment. This is the widely accepted layperson’s definition, and it’s the basis of the association people make with respect to the metaphorical principal amount of a technical debt.

That’s unfortunate. Because the metaphorical principal amounts of most technical debts behave very differently from the principal amounts of financial debts, using the term principal to refer to the metaphorical principal associated with a given kind of technical debt is risky. The risk arises from confusing financial principal, which is typically fixed or slowly declining, with the metaphorical principal of technical debt, which can exhibit sudden and dramatic fluctuations. These confusions arise because of unintended associations of the technical debt metaphor.

Using an alternative term that makes the metaphor obvious can limit this risk. One such term is metaphorical principal, or for convenience, MPrin.

Although the distinction between the initial principal amount of a technical debt and MPrin is not universally recognized [Seaman 2013], some have addressed it. For example, Avgeriou et al. define the initial principal of a particular class of technical debt as the savings realized by incurring the debt, and the current principal as the resources required to deploy a different or better solution now [Avgeriou 2016].

The initial principal concept of Avgeriou et al. is what we call in this blog the MPrin at the time the debt is incurred, or initial MPrin. Although the initial MPrin does have some value for decision makers at the time the debt is incurred, it’s most valuable when deciding whether or not to incur the debt, if, indeed, one has an opportunity to make such a decision. However, once the debt has been incurred, the current MPrin is what matters; initial MPrin becomes irrelevant.

Policymakers must keep clearly in mind that the MPrin of a given kind of technical debt is the total cost of retiring that debt, at the time it is retired, including all cost sources.

We’ll have a look at the policy implications of the properties of MPrin next time.

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:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

Related posts

Balance technical debt and engineering resources

Last updated on December 11th, 2018 at 09:42 am

Improving organizational effectiveness in technical debt management—or avoiding incurring new technical debt—should create significant savings, and many competitive advantages. These benefits should arise from the reductions in metaphorical interest charges that result from retiring technical debt. But these benefits become available to the organization only if engineering capacity increases relative to the burdens presented by the remaining reduced levels of technical debt. After the technical debt management program is in place, if the balance between engineering resources and the burdens imposed by the remaining technical debt becomes more favorable, then organizational effectiveness will improve. But if the balance becomes less favorable, as a result of reductions in engineering resources,  organizational effectiveness won’t improve, even at lower levels of technical debt.

Flooding from Hurricane Katrina in New Orleans, 2005.
Flooding from Hurricane Katrina in New Orleans, 2005. Any levee humans can  build can be overtopped or undermined by the forces of Nature. So it is with  technology. Any technology humans can devise to attain mastery over technical debt can be overcome or undermined by organizational policy and organizational politics. To master technical debt, technology is not enough—we must also deal with policy and politics.

Unfortunately, it’s possible to adopt advanced technical debt management practices while at the same time reducing engineering capacity to a level such that engineering effectiveness is no better than it was before the technical debt management program was initiated. The reason for this is that the engineering process is not the sole cause of technical debt. Improving the engineering process to eliminate technical causes of technical debt leaves non-technical causes in place. That’s why technological solutions to the technical debt management problem might not be sufficient to produce benefits in organizational effectiveness and agility.

The focus of research in technical debt management has been on technology—recognition of technical debt, its measurement, representation, retirement, and so on. Progress on improving the engineering process has been significant, especially in software engineering, where a clear “research roadmap” has been developed [Izurieta 2017]. It’s reasonable to assume that effective tools for automating or partially automating technical debt detection and retirement will be widely available and very generally effective in the not-too-distant future, at least for software. But progress has not been confined to debt detection and retirement. Avoiding technical debt formation to the extent possible is much preferable, and in some contexts, it’s practical even today, as Trumler and Paulisch suggest [Trumler 2016].

But it’s also reasonable to ask whether such developments will have much impact on the limiting effects of carrying technical debt, even in software. Given the necessary resources, much of the technical debt now extant could be retired. That is, debt retirement rates are determined only by the will and the capacity to invest in debt retirement. Currently, the levels of will and capacity for such activity are insufficient. But if new methods for managing technical debt become available, one might wonder whether organizations will apply resources sufficient to ensure that they actually experience a reduction in the limiting effects of technical debt.

The open question is this: will technological developments alone suffice to gain control of the problem of technical debt? Perhaps not. Organizations could exploit the advancements in technical debt management to execute reductions in engineering staffing—and therefore cost—while they divert savings to other parts of the enterprise, thereby allowing technical debt to remain at levels that, although much reduced, are nevertheless sufficient to compromise the effectiveness of that reduced engineering staff.

For example, schedule pressure is widely recognized as contributing to technical debt formation and persistence. If engineering groups become more adept at managing and preventing technical debt, but marketing and sales groups do not improve their own intelligence and planning processes and consequently demand new capabilities with even shorter timelines than they now do, the enterprise might not benefit from the new technical debt management capabilities, even though the burden of technical debt has been reduced.

Until we have evidence of significant change in the behavior of non-technologists—or even acknowledgment that their behavior contributes to debt formation—we can expect the effects of non-technical causes of technical debt to persist, and possibly even to grow.

This blog focuses on the non-technical etiology of technical debt formation and persistence, and approaches for managing it. Watch this space.

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:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42:1, 28-31, 2017. doi:10.1145/3041765.3041774

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10

Cited in:

Related posts

A policymaker’s definition of technical debt

Last updated on January 20th, 2019 at 01:54 pm

Policymakers have in mind the best interests of the entire enterprise. They need a definition of technical debt that is neutral relative to its causes and manifestations, because defining technical debt in terms of what caused it or where it lies in the enterprise could compromise that necessary neutrality.

Servers like the ones that made this page available to you
Servers like the ones that made this page available to you. Cybersecurity is concerned with defending servers like these, among others.

For example, if enterprise policy assumes that technical debt is something that lies only in software, and if the root causes of some instances of technical debt are new and developing threats in the cybersecurity environment, then enterprise policy vis-à-vis technical debt is likely to be ineffective. It might lead to decision makers focusing too much attention on the software development process and too little attention on the cybersecurity and threat intelligence processes.

Here’s a cause-neutral and manifestation-neutral definition of technical debt, what I call the policymaker’s definition [Brenner 2017a]:

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.

Extending the technical debt metaphor just a bit, people often talk about the principal and the interest charges associated with a technical debt, by analogy to the principal and interest charges associated with a financial debt. They’re convenient concepts, but the parallels between finance and technology aren’t real, and that’s where the trouble lies. Read more

There’s one other generalization contained in this definition of technical debt that differs from most other definitions. It’s in the phrase “or missing from.” Our policymaker’s definition doesn’t require that the technical debt item actually exist. That is, the absence of something can constitute technical debt. My favorite example of this was put forward by Ken Pugh, who defines acceptance test debt as “…the nonexistence or nonautomation of acceptance tests.” [Pugh 2010] If we seek to encompass all sources of reduced organizational responsiveness or unnecessary operating expense arising from technical debt, the definition of technical debt that we require must also address non-existence issues such as those identified by Pugh.

The definition above is workable for systems of all kinds. Consider two examples of “hardware”:

But the definition also applies to anything that is manifested in technological forms, including business plans, legislation, procedures, and microprocessor designs—almost anything.

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:

[Brenner 2017a] Richard Brenner. “A Policy Maker’s Definition of Technical Debt,” Cutter Consortium Executive Update, February 27, 2017.

Cited in:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42:1, 28-31, 2017. doi:10.1145/3041765.3041774

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10

Cited in:

Related posts

Technical debt in a rail system

Last updated on June 14th, 2018 at 08:24 pm

Acela Express rounds a curve in Connecticut
Acela Express rounds a curve in Connecticut. Shown is the trailing power car of a southbound Acela Express and the front of a northbound Metro-North railcar.

Most definitions of technical debt require that the asset bearing the debt be software. From the policymaker’s perspective, this requirement is rather limiting. So for the purposes of this blog, I define technical debt as any property of a technological asset that we would like to revise, replace, or create, and which limits the ability of the enterprise to gain or maintain a dominant market leadership position.

Consider an example from the railroad industry. In the United States, the highest-speed rail line is Acela Express, which travels in the northeast corridor between Boston and Washington, D.C. Parts of the right-of-way, track, and catenary it uses were not originally designed for this application, and therefore trains cannot operate at their highest possible speed [Maloney 2000]. On the 231-mile section from Boston to New York’s Penn Station, Acela achieves an average speed of only 63 mph (101 km/h), even though the trains can operate safely on straight track at 150 mph (240 km/h). Yet, Acela still manages to capture a 54% share of the total air and rail market between these two cities.

That 54% share might be higher still if not for technical debt. To compensate for centrifugal forces as Acela Express rounds curves, its passenger cars are able to tilt the passenger spaces to enable the train to round the curves at higher speeds than would otherwise be comfortable for passengers. In effect, the cars “lean into” the curves, just as a running athlete leans when making a sudden change of direction. Although the cars were designed to be able to tilt by as much as 6.8º, the adjacent set of tracks is too close to permit this without risk of collision with trains on those tracks. The maximum tilt is therefore set at 4.2º, which, in turn, reduces the maximum speed consistent with passenger comfort that the trains can attain on curves. The technical debt manifested in the tracks Acela Express uses thus prevents it from offering a service that would be more competitive with alternative transport modes, especially airlines.

Note: In August 2016, Amtrak announced that it will be upgrading its trainsets and tracks to exploit new technologies, including active tilt technologies. All existing trainsets are due to be replaced in 2021-22.

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:

[Brenner 2017a] Richard Brenner. “A Policy Maker’s Definition of Technical Debt,” Cutter Consortium Executive Update, February 27, 2017.

Cited in:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42:1, 28-31, 2017. doi:10.1145/3041765.3041774

Cited in:

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10

Cited in:

Related posts

Technical debt in the highway system

Last updated on December 11th, 2018 at 11:26 am

The ghost ramps of highway I-695 in Somerville, Massachusetts
The ghost ramps of highway I-695 in Somerville, Massachusetts. Photo (cc) Nick Allen.

Interstate 695 was planned in 1955 as an “inner belt” circumferential route in Boston and adjacent towns. When it was cancelled in 1971, construction had already begun. Rights of way that had been cleared have since been reused for roads and mass transit, but some never-used structures remain to this day, including a “ghost ramp” in Somerville that would have connected I-695 to I-93. This ramp, which is a mere stub that begins on an elevated stretch of I-93 and ends in mid-air, and which is blocked off to prevent use, constitutes technical debt in the form of incomplete implementation. Google satellite view

For safety reasons, the ghost ramp must be regularly inspected, maintained, and insured, but it provides no utility and it is not used for any civic purpose. Because the cost of retiring this technical debt—namely, demolition costs—would likely exceed the present value of the lifetime costs of inspection, maintenance, and insurance, the ghost ramp remains.

Sometimes, the best way to deal with technical debt is to leave it in place.

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:

[Brenner 2017a] Richard Brenner. “A Policy Maker’s Definition of Technical Debt,” Cutter Consortium Executive Update, February 27, 2017.

Cited in:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42:1, 28-31, 2017. doi:10.1145/3041765.3041774

Cited in:

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10

Cited in:

Related posts

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

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

[Brenner 2017a] Richard Brenner. “A Policy Maker’s Definition of Technical Debt,” Cutter Consortium Executive Update, February 27, 2017.

Cited in:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42:1, 28-31, 2017. doi:10.1145/3041765.3041774

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:

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10

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:

[Brenner 2017a] Richard Brenner. “A Policy Maker’s Definition of Technical Debt,” Cutter Consortium Executive Update, February 27, 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:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42:1, 28-31, 2017. doi:10.1145/3041765.3041774

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:

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10

Cited in:

What is policy?

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

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

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

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

References

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

[Brenner 2017a] Richard Brenner. “A Policy Maker’s Definition of Technical Debt,” Cutter Consortium Executive Update, February 27, 2017.

Cited in:

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

Cited in:

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

Cited in:

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

Order from Amazon

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42:1, 28-31, 2017. doi:10.1145/3041765.3041774

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:

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10

Cited in:

Related posts

Who are the policymakers?

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

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

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

References

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

[Brenner 2017a] Richard Brenner. “A Policy Maker’s Definition of Technical Debt,” Cutter Consortium Executive Update, February 27, 2017.

Cited in:

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

Cited in:

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

Cited in:

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

Order from Amazon

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42:1, 28-31, 2017. doi:10.1145/3041765.3041774

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:

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10

Cited in:

Related posts

Show Buttons
Hide Buttons