Separating responsibility for maintenance and acquisition

Last updated on February 1st, 2018 at 05:59 am

Separating responsibility for maintenance and acquisition of technical assets can lead to uncontrolled growth of technical debt. When the performance of the business acquisition function or the performance of the development organization is measured without regard for the technical debt that arises as a consequence of their actions, technical debt is likely to expand unchecked. To limit such expansion, policymakers must devise performance measures that hold these organizations accountable for the technical debt arising from their actions.

Road damage in Warwick, Rhode Island, resulting from historic storms in March 2010
Road damage in Warwick, Rhode Island, resulting from historic storms in March 2010 [NOAA 2013]. The storms were so severe that at least one river flood gauge “flat-lined” — the floodwaters overtopped the gauge’s measurable range. Moreover, the National Weather Service (NWS) lacked a database of measurable ranges for flood gauges. Quoting the NWS report: “A lesson learned here was that maximum recordable river levels should be known by NWS staff, not only so staff aren’t surprised when this type of issue arises, but also to notify USGS personnel so that they can install a temporary gage and remove or elevate threatened equipment.” Technical debt, if ever I’ve seen it.
For systems consisting solely of software, separation of responsibility for system maintenance and system development or acquisition enables the acquiring organization to act with little regard for the consequences of its decisions vis-à-vis maintenance matters [Boehm 2016]. This is an unfortunate state of affairs that increases the rate of accumulation of new technical debt, and increases the lifetime of legacy technical debt, because the MICs associated with the technical debt aren’t borne by the acquiring organization.

For example, a focus on performance of the organization that’s responsible for acquisition biases them in favor of attending to the direct and immediate costs of the acquisition, with little or no regard for ongoing maintenance issues. The maintenance organization is then left to deal with whatever the acquired system contains (or lacks).

An analogous mechanism operates for organizations that develop, market, and maintain products or services with software elements in their respective infrastructures. In that case, separation of the development function from the maintenance function enables the development function to act independently of the consequences of its decisions for maintenance matters.

But the separation-of-responsibilities mechanism that leads to uncontrolled technical debt isn’t restricted to software. Any technological asset that has ongoing maintenance needs (and most of them do) can potentially present this problem.

For example, in the United States, and many other countries, two streams of resources support publicly-owned infrastructure [Blair 2017]. The funding stream covers construction, operations and maintenance, and repairs. Its usual sources are taxes, tolls, licenses, other user fees, sale of ad space, and so on. The financing stream covers up-front construction costs, to bridge the period from conception through construction, until the funding stream begins delivering resources. The financing stream usually comes from bond sales.

Although both streams are controlled by legislatures, or by agencies they establish, the effects of the two streams differ fundamentally. The financing stream is dominant in the early stages of the asset’s lifecycle — during construction. The funding stream is dominant after that — when maintenance and operations are most important. Legislators and agencies are generally reluctant to supply funding because of the impact on taxpayers and users. Legislators and agencies find financing much more palatable. For this reason, among others, U.S. infrastructure maintenance is generally under-resourced, and technical debt gradually accumulates.

So it is with technological assets in organizations. For accounting purposes, capital expenses are treated differently from operational expenses, and the result is that operational expenses can have a more significant impact on current financial results than capital expenses do. This leads organizations to underfund operations and maintenance, which contributes to the accumulation of technical debt.

Control of new technical debt accumulation and enhancement of technical debt retirement rates is possible only if the acquisition or development organizations can somehow be held accountable for the MICs that result from their actions. Securitization of the debt incurred, as I’ll address in a forthcoming post, is one possible means of imposing this accountability. But reserves are also required, because some of the debt incurred might not be known at the time the asset is acquired or created.

Separation of responsibility for system maintenance and system acquisition or system development is actually a form of stovepiping. See “Stovepiping can lead to technical debt” for more on stovepiping.

References

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Other posts in this thread

Zero tolerance and work-to-rule deliveries create an adversarial culture

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

Defining technical debt at the level of specificity needed for project objectives is difficult. Confronted with this difficulty, some internal customers of technologists adopt a zero-tolerance approach to technical debt, without specifically defining technical debt. Post-delivery — sometimes much, much, post — when technical debt is discovered or recognized, technologists are held responsible, even in cases when no one could have predicted that a specific artifact would eventually come to be regarded as technical debt. This sets up an adversarial dynamic between technologists and their internal customers.

Delayed or cancelled flights
Trouble at the airport. When airline pilots engage in work-to-rule actions, the immediate result can be large numbers of delayed or cancelled flights. The longer-term result might be beneficial to pilots, the airline, and the public, but only if labor peace can be restored, and the damage to the flying public can be overcome. So it is with work-to-rule deliveries as a way of dealing with zero-tolerance technical debt policies. The organization must overcome the adversarial culture that results from indiscriminate attempts to control technical debt. Technologists do gain some measure of protection by working to rule, but the longer-term benefit of the organization’s learning to manage technical debt arrives only if the adversarial culture can be overcome. Image (cc) Hotelstvedi courtesy Wikimedia.

And that’s when the trouble begins.

Within this adversarial dynamic, technologists try to protect themselves against future recriminations by “working to rule.” They perform only work that is specified by the internal customer. If they find something additional that must be done, they perform that work only if they successfully obtain the customer’s approval. Some customers continue to adhere to a zero-tolerance policy with respect to technical debt, but such a non-specific requirement cannot be met. Because technologists are “working to rule,” they use the ambiguity of the zero-tolerance requirement to assert that they performed all work that was sufficiently specified. This level of performance is analogous to the work-to-rule actions of some employees involved in labor disputes with their employers, and who are literally in compliance with the requirements of the employer, but only literally [LIBCom 2006].

Requiring deliverables to be totally free of technical debt contributes to formation of an adversarial culture, wherein the adversaries are the technologists and their internal customers. Shedding that adversarial culture, once it sets in, can be difficult. Compelling employees, vendors, or contractors to deliver work that’s free of all technical debt is therefore unlikely to succeed. Whether work is performed in-house by employees, or is outsourced, or is performed in-house by contractors, deliverables that meet the minimum possible interpretation of the objectives of the effort are almost certainly burdened with unacceptable levels of technical debt. What can we do to prevent this?

To avoid creating an adversarial culture, we can specify in project objectives some kinds of technical debt that must be removed in toto. To ensure steady progress in technical debt retirement, develop a statement of objectives that includes complete retirement of at least one well-defined class of technical debt, emphasizing debt classes that have the highest anticipated MICs in the near term. Other well-defined classes of technical debt can be addressed on a best-effort basis.

We must accept that any other forms of technical debt that remain at the end of a given project, or any constructions that later come to be recognized as technical debt, are just the “cost of doing business.” We’ll get to them, but unfortunately, not this time.

References

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Other posts in this thread

Self-sustaining technical knowledge deficits during contract negotiations

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

Enterprises that grow by acquisition find themselves acquiring the technological assets of the organizations they acquire. And most enterprises acquire technological assets by other means as well. In either case, the contract negotiation teams need technical knowledge to evaluate and project the effects of these acquisitions on total enterprise technical debt. But as total enterprise technical debt grows, the capacity of enterprise technologists to support new contract negotiations declines, which leads to a self-sustaining cycle of technical knowledge deficits. Policymakers and strategic planners are likely the most effective possible advocates for breaking the cycle by hiring more technologists.

Avoid technical knowledge deficits in important contract negotiations
Contract negotiations can be complex

Negotiating contracts with vendors that provide outsourcing services or subcontracting work, or with organizations to be acquired, requires a sophisticated appreciation of the technical debt status of the assets acquired or to be acquired. The technical debt in question includes more than just the debt borne by the asset as it stands in its pre-acquisition context. It also includes the debt that the asset will carry after it’s inserted into the asset portfolio of the acquiring enterprise.

These two debts — pre-acquisition and post-acquisition — can differ, because the interfaces, standards, and approaches of the acquiring organization likely differ from those prevailing within the vendor organization or the acquired organization. Knowledge of the interfaces, standards, and approaches of both parties to the transaction is therefore required to make a valid assessment of the total post-acquisition levels of technical debt.

The enterprise negotiation team therefore requires the services of technologists who are familiar with the maintenance, extension, and cybersecurity work that will be performed on the acquired assets post-acquisition. When the technical debt situation in the enterprise reaches a level so serious that it requires the full attention of all available technologists, they cannot be spared for negotiating contracts. If this happens, then contract negotiation teams could experience a deficit of knowledge concerning the consequences of acquiring assets laden with technical debt. That leads to increasing levels of non-strategic technical debt, which then has the potential to exacerbate the technical knowledge deficit for the negotiating teams.

This situation is an example of what’s commonly called a vicious cycle. After technical debt has reached a critical level, there are really only two tactics that can break the cycle — get more engineers, or suspend some work.

References

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Other posts in this thread

Where the misunderstandings about MICs come from

Last updated on December 21st, 2017 at 04:27 pm

The differences between technical debt and financial debt are numerous and significant, and often overlooked, in part, because of the metaphor itself. Attempting to manage technical debt as one would manage financial debt is risky for two reasons. First, such an approach would most likely fail to exploit properties of technical debt that can reduce the costs of both carrying and retiring technical debt. More important are the opportunities lost or unrecognized because of reticence about addressing the technical debt to the extent necessary if we were to exploit those opportunities.

The right tool for the wrong job
Managing technical debt by using approaches that work well for financial debt is analogous to using the right tool for the wrong job.

The debt metaphor itself is probably at the root of the misalignment between the conventional concept of fixed or slowly varying interest rates and the reality of loss of enterprise agility or lost revenue due to technical debt. For the more familiar kinds of financial debts, the interest rate and any rules for adjusting it are set at the time of loan origination. Moreover, financial debts are unitary in the sense that each loan is a single point transaction with a single interest rate formula. For example, the interest rate formula for the most common kind of credit card balance is the same for every purchase. Technical debt isn’t unitary — each kind of technical debt and each manifestation of that kind of technical debt is, in effect, a separate loan that can carry its own independently variable MICs.

The cost of carrying technical debt can vary with time. It can vary for a given class of technical debt, or it can vary instance-by-instance. Costs depend on the nature of the work undertaken on the assets that carry the debt. This fact is a source of flexibility useful for planning technical debt management programs, which can exploit it to set priorities for debt retirement and debt prevention efforts. That flexibility implies, for instance, that planning technical debt retirement programs to satisfy the urge to retire all instances of a given class of technical debt might not be sensible.

When making technical debt management decisions, respect the constraints that technical debt imposes. Exploit the flexibility that technical debt provides.

References

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Related posts

MICs can change when other debts are retired

Last updated on December 22nd, 2017 at 12:17 pm

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 some kinds of technical debt.

Financial debts usually have associated interest rates that are used to compute the periodic interest charges. Typically, the interest charge on a financial debt for a given period is the periodic interest rate multiplied by the principal, and then scaled for the length of the time period.

But there are no “rates” for technical debt. Their existence would imply that MICs were proportional to the analog of “principal,” which, in the case of technical debt, is the cost of retiring the debt — the MPrin. MICs depend only weakly on the cost of retiring the debt. Instead, they depend more strongly on the impact of the debt on ongoing operations.

Decision-makers who understand the world of financial instruments at a very sophisticated level might tend to overvalue arguments favoring technical debt management in ways analogous to the ways we manage financial debts. Financial sophisticates might find appealing any argument for a technical debt management program that parallels financial approaches. Such programs are unlikely to work, for two reasons. First, as we’ve already noted, the uncertainties associated with estimating MPrin and MICs make technical debt management decisions more dependent on engineering and project management judgment than they are on the results of calculations and projections (see MPrin uncertainties and MICs uncertainties).

Second, as noted above, the familiar concept of interest rate is inapplicable to technical debt, because the MICs depend on the degree of interaction between ongoing activities and the debt itself, rather than the cost of retiring the debt. And that means that MICs (and MPrin) of one class of debt can change when another class is retired.

Implications of this effect

The possibility that retiring one class of technical debt can alter the financial burdens presented by another class of technical debt has both favorable and unfavorable implications.

MICs can change when other debts are retired
An example illustrating one way in which MICs on one kind of technical debt  can change as a result of retiring a different kind of technical debt. The structure at the left represents the situation before any debt retirement occurs. The balloons labeled “A” represent instances of asset A. The balloon labeled “B” represents asset B. The orange circles represent instances of technical debt D1 and D2, respectively. The arrows connecting the As to B indicate that asset A depends on Asset B. The structure at the right represents the situation after debt retirement.

As an example of a favorable implication, consider software remodularization. Suppose we have a software asset A that depends on another software asset B. As shown in the left image of the figure, asset A, of which there are many copies, bears two classes of technical debt, D1 and D2. As shown, there is only one copy of asset B. Suppose further that an asset that bears debt D2 also bears debt D1, but an asset that bears D1 might or might not bear debt D2.

To retire D2, engineers have decided to modify B by having it assume responsibility for the tasks that formerly bore debt type D2. They do this even though, as a consequence of this change, B will now bear debt of type D1. Next, debt type D2 is retired. The right half of the figure shows the resulting implementation. The system still bears debt D1, but now it’s located in B instead of A. All instances of type A assets change, and those modifications relieve them of both types of debt. This is a sensible approach, because there are several assets of type A and only one of type B. The end result is that D2 vanishes, and only a single instance of D1 remains. In this way, retiring debt D2 has reduced the MICs and MPrin for D1.

Policymakers can help

Exploiting the salutary opportunities of this property of technical debt provides an example of the risks of adhering too closely to the financial model of debt.

Many different scenarios have the property that retiring one kind of technical debt can reduce the MICs associated with other kinds of debt. Because technologists understandably tend to be more concerned with technical debt retirement strategies that emphasize short-term improvement of their own productivity, policymakers can provide guidance that steers the organization in the direction of enterprise benefits.

References

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Related posts

MICs on technical debt can be difficult to measure

Last updated on December 25th, 2017 at 06:43 am

For a financial debt, creditors regularly inform debtors of periodic interest charges, principal remaining, and other parameters of the loan. In many cases, laws require regular reports and explicit statements about interest charges when prospective creditors interact with prospective debtors. By contrast, for technical debt, MICs can be difficult to compute with useful precision, even if we know that they’re accumulating. Many decision-makers are actually unaware that MICs are accumulating at all. For an organization to appreciate the full financial consequences of carrying technical debt, everyone in the enterprise must appreciate the concept of MICs.

A stack of floppy disks
A stack of floppy disks. You don’t see many of these around much anymore. Very little of the software or hardware we use is as obsolete as these floppies. But much of it is obsolete, and it therefore comprises technical debt. It still works, but it’s slow and probably no longer supported by its manufacturer. On the basis of speed alone, the MICs it incurs can easily justify replacement. And some of it is vulnerable to cyberattack. One significant breach can ruin a brand.

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.

The difficulty of measuring MICs arises from three sources. First, people whose productivity is most directly affected by technical debt — usually engineers — often have difficulty determining with precision the extent of the impact of technical debt on their efforts.

Second, many people are unaware of the impact technical debt has on their results. For example, if a product arrives late to market, the financial costs attributable to technical debt can be computed if we realize that technical debt is partially — or wholly — responsible for the delay. Too often, those who could perform such calculations aren’t sufficiently familiar with the concept of MICs, and in any case, the data they would need for calculating a useful estimate is rarely available.

Finally, a more insidious form of the consequences of technical debt is what we might call the terrifying opportunity. This situation 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 depressed by technical debt that the opportunity seems terrifying, and they therefore reject the opportunity. Typically, terrifying opportunities would be exploitable if the debt-bearing assets didn’t exist at all, because then we would be starting fresh. But given that terrifying opportunities require modifying existing assets that bear heavy loads of technical debt, commitment requires faith that the technical debt can be addressed successfully.

The sense of risk isn’t a reflection on the capabilities of the technical organization. Rather, it is a result of the challenges involved in working with assets that bear high levels of technical debt. Given past performance of the technical organization relative to these debt-bearing assets, success can seem unlikely.

Computing the cost of a terrifying opportunity requires estimating the cost of not exploiting the opportunity, a difficult task in the best of circumstances. But whatever that cost is, it’s a form of MICs that we rarely recognize.

Building expertise in estimating MICs in all their forms is advantageous to any organization that seeks to make its technical debt more manageable. By making MICs visible, we can bring about better recognition of the cost of carrying technical debt, thereby providing an appropriate motivator for retiring technical debt.

References

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Related posts

MICs can sometimes be deferred or advanced without penalty

Last updated on December 26th, 2017 at 07:57 pm

Although rescheduling interest payments on financial debts is possible only by prearrangement, by special arrangement, or in bankruptcy, MICs on technical debt can often be deferred or advanced by simply rescheduling any work that might incur them. This is possible because, for some kinds of technical debt, MICs accumulate only if we perform engineering work that’s affected by that debt. This property is especially useful when we plan to retire an asset that bears technical debt, because when it’s removed from service, the technical debt it carries vanishes.

A rehabilitated Green Line car of the Massachusetts Bay Transit Authority
A rehabilitated Green Line car of the Massachusetts Bay Transit Authority. Trolley cars still travel on surface streets in Boston, but the only active lines are in medians of divided roadways. Many streets in and around Boston still contain buried trolley tracks. They comprise a technical debt, and MICs continue to accrue in the form of broken pavement and a near-continuous need to patch roadways, due to surface decomposition from the freeze-thaw cycle and the constant small movements of the buried tracks due to traffic loads. A recent sewer upgrade project in Cambridge required removal of buried tracks to remove and replace the old sewer line. This presented an opportunity to defer street surface maintenance (MICs) to take advantage of the surface rebuilding that was included in the sewer project, though I don’t know whether that opportunity was actually exploited.

For most conventional financial debts, interest charges accumulate until the debt is retired. Interest charges might be zero for defined time periods, but they’re never negative. Failure to meet the contractual payment schedule can result in penalties and additional interest charges.

But at times, for technical debt, MICs can be deferred or advanced without penalty and without additional “interest charges.” In other words, the organization can arrange to temporarily nullify the MICs on a particular class of technical debt, or for particular instances of that class, by simply rescheduling a project or projects. This is possible when the nature of the debt is such that MICs accrue only if there is a need to perform work on assets that are affected by the debt in question. In a given fiscal period, if no work is performed on those assets, the MICs can be zero. By scheduling projects accordingly, organizations can arrange for MICs to be zero.

There is one caveat. As discussed in “How technical debt can create more technical debt,” as long as a particular class of technical debt remains in place, its associated MPrin might increase. Deferring retirement of a class of technical debt is wise only if its associated MPrin is controlled or if projected changes in its MPrin are acceptable.

References

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Related posts

MICs can differ for different instances of the same kind of technical debt

Last updated on November 30th, 2017 at 02:38 pm

For financial debts, the interest charges associated with a unit of debt are (usually) the same for every unit of debt incurred under the same loan agreement. But for technical debt, the MICs associated with a given instance of a class of technical debt might differ from the MICs associated with any other instance of the same class of technical debt, even if those instances of technical debt were incurred at the same time as a result of a single decision or sequence of events.

Collapse of the I-35W bridge in Minneapolis, Minnesota
The I-35W Bridge collapse, day 4, Minneapolis, Minnesota, August 5, 2007. The proximate cause of the collapse was underweight gusset plate design, which made the bridge vulnerable to the increased static load due to concrete road surfacing additions over the years, and to the weight of construction equipment and supplies during a repair project that was then underway. But the root cause of the failure was that the design of the bridge was “fracture critical,” meaning that it was vulnerable to collapse if any one of a set of critical bridge members failed. There are 18,000 fracture critical bridges in the U.S. today, and more are under construction. They were built (and are being built) because they’re cheaper to build than are bridges that have zero fracture critical members [CBS News 2013]. Engineering practices like this—expedient shortcuts—are among the most prolific generators of technical debt. The MICs in the case of bridges could include inspections, repairs, and temporary closures for inspections and repairs. Variations in bridge design and usage clearly could create variations in MICs from bridge to bridge. Photo by Kevin Rofidal, United States Coast Guard,  courtesy Wikimedia Commons.

Here’s why.

For most financial debts, a single algorithm determines the interest charges for every unit of a particular class of financial debt. Following the technical debt metaphor, people tend to assume that the MICs on every instance of a particular class of technical debt are uniform across the asset base.

But in practice, uniformity assumptions with regard to MICs are generally unwarranted. Given two different manifestations of the same kind of technical debt, the MICs associated with modifying asset components in and around those two instances can differ significantly. For any given instance of a particular class of technical debt, MICs can depend on whether or not engineers must interact with that part of the asset. And when they do interact with a given asset component, MICs can also depend upon the transparency and condition of that asset component.

For example, an instance of technical debt might reside in a portion of the system that relatively few local experts understand. The people who are capable of doing that work might be in high demand, or heavily committed, or expensive. Subsequent scheduling difficulty can lead to delays or service interruptions associated with completing the required work. That can result in lost revenue, which also contributes to MICs. Meanwhile, instances of the same kind of technical debt residing in other parts of the asset might be addressable by less expert staff, who might be in lesser demand, and less well compensated. Service interruptions might be shorter, and lost revenue less. The MICs associated with these two cases can therefore differ significantly.

As a second example, consider documentation deficits. If an engineer needs access to documentation to determine how to proceed with a task, and that documentation doesn’t exist, the engineer must resort to alternatives that might be more time-consuming, such as reading code or specifications, or interviewing colleagues. But for two given instances of the same kind of technical debt, the need to refer to documentation can differ. Documentation might be needed for one instance in one part of the asset, but not for another.

Another form of documentation deficit can be especially costly. If documentation is needed, and it does exist, but it’s outdated or incorrect, engineers who rely on that documentation might make costly, potentially irreversible errors when they undertake maintenance or extension activity. A less-damaging case is one in which testing uncovers the defects they unwittingly introduced due to the defective documentation. But if the defects aren’t caught in testing, and if those defects somehow find their way into production, the revenue or liability impact can be substantial, and it can vary from instance to instance of the technical debt in question. These effects are all forms of MICs.

So MICs can vary almost on an instance-by-instance basis. Or they might be constant across instances. It’s difficult to say. But the easy assumption—that MICs are the same for all instances of a given class of technical debt—the easy assumption is probably incorrect.

References

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[CBS News 2013] CBS News and the Associated Press. “Thousands of U.S. bridges vulnerable to collapse,” May 25, 2013.

Available: here; Retrieved: November 29, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Related posts

MICs on technical debt can be unpredictable

Last updated on November 30th, 2017 at 02:38 pm

Few senior management teams would seriously consider making decisions about the use of financial instruments without first developing careful estimates of their effects on revenue and expenses. In most enterprises, there is an impressive array of tools, historical data, and skilled financial professionals to support those who devise or specify financial instruments for use in financing the enterprise. Yet few organizations invest at similar levels to support those who make estimates of the MICs involved in undertaking engineering efforts. A similar deficit of resources affects those who make estimates of the effects on revenue due to carrying technical debt.

A composite satellite view of Antarctica
A composite satellite view of Antarctica. Composite by Dave Pape using NASA’s Blue Marble data set. Exploring unknown territory, as Amundsen did in 1911-12, is far more difficult and far riskier than exploring mapped territory. For this same reason, managing technical debt is likely to be more successful when we have even minimal capability for estimating the MICs associated with carrying or retiring technical debt. Courtesy Wikimedia Commons.

This resource shortage has starkly negative effects, because of the inherent difficulties associated with projecting the effects of both carrying and retiring technical debt.

Although there can be a cost associated with carrying technical debt—I call them MICs—the cost can fluctuate dramatically depending on a range of factors, such as the kind of work underway on the asset that carries the debt; how customers are affected and what they’re doing at any given time; the difficulty of researching engineering problems arising from the debt; loss of revenue due to debt-related delays in reaching the market; loss of sales due to semi-catastrophic failures in customer demonstrations; and much more. In short, the MICs are often unpredictable [Allman 2012].

Moreover, most of the research into the effects of carrying or retiring technical debt has focused on engineering activity, and specifically, software engineering activity [MacCormack 2016][Kamei 2016]. Effects on other activities—marketing, sales, regulatory compliance, to name a few—are, by comparison, largely unstudied. And in many cases, the effects on these other activities are the most significant.

Consider first the effect of technical debt on enterprise expenses. The kind of maintenance and enhancement work performed on a set of assets bearing technical debt can determine the extent to which productivity is depressed, in turn affecting the MICs. In many cases, projecting future MICs associated with any given class of technical debt can be difficult because we might not know with sufficient certainty what projects will be undertaken in the intermediate term or long term future, and what kind of work those projects will undertake. Even when we do know these things, the level of involvement with instances of particular classes of technical debt can be difficult to project with a degree of certainty consistent with most other estimates.

Turning to revenue, for most organizations, the picture is also bleak. Because some classes of technical debt cannot be retired incrementally, attempts to retire them can have significant impact on operations and revenue. Research in this area is even more limited than in the area of effects on productivity.

Projecting MICs with useful accuracy would be a valuable capability. Making MICs more predictable would require systematically gathering data and building expertise for projecting MICs for your enterprise. That problem is more tractable than the more general problem of projecting MICs absent specific knowledge of enterprise characteristics.

An enterprise-specific MICs projection capability could elevate the quality of decisions regarding resource allocation for projects of all kinds, including technical debt retirement projects. Policymakers can play an important advocacy role in establishing such a capability.

References

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

Available: here; Retrieved: March 16, 2017

Cited in:

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[CBS News 2013] CBS News and the Associated Press. “Thousands of U.S. bridges vulnerable to collapse,” May 25, 2013.

Available: here; Retrieved: November 29, 2017

Cited in:

[Kamei 2016] Yasutaka Kamei, Everton Maldonado, Emad Shihab, and Naoyasu Ubayashi. “Using Analytics to Quantify the Interest of Self-Admitted Technical Debt,” 1st International Workshop on Technical Debt Analytics (TDA 2016), 68-71.

Available: here; Retrieved: November 28, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[MacCormack 2016] Alan MacCormack and Daniel J. Sturtevant. “Technical debt and system architecture: The impact of coupling on defect-related activity,” The Journal of Systems and Software 120 (2016) 170–182.

Available: here; Retrieved: November 19, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Related posts

MICs can fluctuate dramatically

Last updated on November 30th, 2017 at 02:37 pm

A common assumption vis-à-vis technical debt is that its productivity-depressing and velocity-reducing effects, usually regarded as interest on the technical debt, can be modeled as relatively constant over time. In practice, the magnitude of these effects can vary dramatically with time, and that variation provides planners valuable insight and flexibility.

30-year average fixed mortgage rates in the United States, 2012-2017
30-year average fixed mortgage rates in the United States, 2012-2017, in %. Over this five year period, although the rate did fluctuate, it did so in a narrow range of 3.3% to just over 4.5%. When we speak of “interest,” we tend to evoke an impression of relative stability, even when we’re speaking of technical debt, where MICs can vary from 0 to well above MPrin in any given time period. That’s one thing that makes the term “interest” so misleading in the context of technical debt. Data provided by U.S. Federal Reserve Bank of St. Louis [Federal Reserve 2017].
As an example of this assumption, Buschmann states that the longer we wait to retire technical debt in design and code, the larger the amount of interest [Buschmann 2011]. This presumes constant, or at least non-negative, metaphorical interest charges, an assumption that might be valid for some situations, but which is not universally applicable. Those projects that entail maintenance or extension of parts of the system that don’t manifest a specific class of technical debt, and which don’t depend on elements that do manifest it, are much less likely to incur the MICs associated with that debt. So with respect to any particular class of technical debt, during time periods in which no projects incur MICs, the interest accrued in those periods can be zero. In other time periods, the interest accrued on account of that same class of technical debt could be very high indeed.

These effects are quite apart from the tendency of MPrin to grow with time, as we noted in an earlier post (see “How technical debt can create more technical debt”).

A capacity for projecting MICs associated with a particular class of technical debt can be useful to planners as they work out schedules for maintenance projects, development projects, and technical debt retirement projects. Technical debt retirement projects are also subject to MICs, including from classes of technical debt other than the debt they’re retiring.

Analogous to the functioning of governance boards, a technical debt resources board could provide resources for evaluating assessments of likely MICs for maintenance projects, development projects, and technical debt retirement projects. Decision makers could use these assessments when they set priorities for these various efforts. I’ll say more about technical debt resources boards in future posts.

References

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

Available: here; Retrieved: March 16, 2017

Cited in:

[Blair 2017] Hunter Blair. “No free bridge: Why public–private partnerships or other ‘innovative’ financing of infrastructure will not save taxpayers money,” Economic Policy Institute blog, March 21, 2017.

Available: here; Retrieved: January 29, 2018

Cited in:

[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.

Available: here; Retrieved: July 25, 2017

Cited in:

[Buschmann 2011] Frank Buschmann. “To Pay or Not to Pay Technical Debt,” IEEE Software, November/December 2011, 29-31.

Available: here; Retrieved: March 16, 2017.

Cited in:

[CBS News 2013] CBS News and the Associated Press. “Thousands of U.S. bridges vulnerable to collapse,” May 25, 2013.

Available: here; Retrieved: November 29, 2017

Cited in:

[Federal Reserve 2017] Federal Reserve Bank of St. Louis. “30-Year Fixed Rate Mortgage Average in the United States (MORTGAGE30US).” Weekly time series.

Available: here; Retrieved: November 25, 2017

Cited in:

[Kamei 2016] Yasutaka Kamei, Everton Maldonado, Emad Shihab, and Naoyasu Ubayashi. “Using Analytics to Quantify the Interest of Self-Admitted Technical Debt,” 1st International Workshop on Technical Debt Analytics (TDA 2016), 68-71.

Available: here; Retrieved: November 28, 2017

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[MacCormack 2016] Alan MacCormack and Daniel J. Sturtevant. “Technical debt and system architecture: The impact of coupling on defect-related activity,” The Journal of Systems and Software 120 (2016) 170–182.

Available: here; Retrieved: November 19, 2017.

Cited in:

[NOAA 2013] NOAA/National Weather Service. “The March, 2010 Floods in Southern New England,” WFO Taunton Storm Series Report #2013-01, January 2013.

Available: here; Retrieved: January 30, 2018

Cited in:

Related posts