Tag: responsibility

Posted on

Separating responsibility for maintenance and acquisition

Last updated on July 8th, 2021 at 01:28 pm

Separating responsibility for maintenance and acquisition or development of technical assets can lead to uncontrolled growth of technical debt. The problem arises when we measure without regard for technical debt the performance of the business acquisition function or the performance of the development organization. In that circumstance, technical debt is likely to expand unchecked. To limit such expansion, policymakers must devise performance measures that hold these organizations accountable for technical debt resulting from their actions.

Software systems

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 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, separating responsibility for maintenance and acquisition or system development is risky. It enables the acquiring organization to act with little regard for the consequences of its decisions vis-à-vis maintenance matters [Boehm 2016]. This is unfortunate—it increases the rate of accumulation of new technical debt. And it increases the lifetime of legacy technical debt. This happens more frequently when the acquiring organization doesn’t suffer the MICs associated with the technical debt.

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. They are likely to have little or no regard for ongoing maintenance issues. The maintenance organization must then deal with whatever the acquired system contains (or lacks).

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

Systems that include hardware

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 legislatures, or agencies they establish, control both streams of resources, the effects of the streams differ fundamentally. The financing stream is dominant during construction and the early stages of the asset’s lifecycle. 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, funds for U.S. infrastructure maintenance are generally insufficient, and technical debt gradually accumulates.

So it is with technological assets in organizations. For accounting purposes, capital expenses are treated differently from operational expenses. 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 technical debt accumulation.

Last words

Control of new technical debt accumulation and enhancement of technical debt retirement rates is possible only if we can somehow hold accountable the acquisition or development organizations 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.

Separating responsibility for maintenance and 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

Posted on

On assigning responsibility for creating technical debt

Last updated on July 7th, 2021 at 03:19 pm

An engineer attending a meeting
An engineer attending a meeting with 14 other engineers. You can’t see the other 14 because they’re at least 4,000 miles away in four separate locations.

When we discover an issue within our organizations, two intertwined imperatives demand attention: “How did this happen?” and “What do we do about it?” As we address the former question, almost inevitably we begin to decide who was responsible for creating the problem. Even if we succeed in avoiding blamefests (see [Brenner 2005a]) we can still make gross errors. Aassigning responsibility for creating technical debt can be a fraught exercise.

Assigning responsibility for creating technical debt provides some clear examples of the many dangerous traps that await us on the path to Truth. How we assign responsibility is due, in part, to patterns of organizational culture.

Causes of growth in technical debt

The causes of growth in technical debt are numerous. They include—among many others—insufficient resources, schedule pressure, existing technical debt, changes in strategic direction, changes in law or regulations, and the risks associated with creating first-of-kind solutions to difficult problems. In most engineering activity new technical debt is inevitable. How we deal with it is up to us.

Unfortunately, many organizations don’t provide the time or resources needed to retire that new technical debt on a regular basis.

When technologists—engineers, their managers, or others in technical roles—try to alert the rest of the organization (non-technologists) to the problems that follow from continually accumulating technical debt, they often meet resistance from non-technologists. Technologists usually hope that intensive education programs can lead to resolving this resistance.

Sometimes education works. Sometimes technologists do receive the additional resources, time, and cooperation they need to start retiring the accumulated technical debt, and to avoid adding more debt to the burden they already carry.

Misconceptions about the causes of technical debt

Mostly, though, education programs don’t work, for reasons beyond mere misunderstanding of the issue. One fundamental problem is the word “technical” in the term technical debt. Non-technologists must be forgiven for believing that since technical debt is inherently technical, it follows that its causes are also technical, that technologists are solely responsible for creating technical debt, and that non-technologists play no role. Those conclusions are, of course, false, but the beliefs persist, and many non-technologists adopt the view that “It’s your problem—fix it.”

A second cause of misconceptions about the causes of technical debt lies in the belief that technologists aren’t working very hard. This belief is founded on assumptions many of us make about what diligent work looks like. Many non-technologists have roles in General Management, Sales, Marketing, or Business Development. They’re working hard when they’re in contact with each other or with people outside the enterprise. They’re traveling, conversing by telephone, or attending or hosting meetings. By contrast, technologists are working hard when they’re at their desks, or attending (face-to-face or virtual) meetings. They do attend meetings off premises, but they do so at much lower rates than do many non-technologists.

When non-technologists assess the technologists’ work ethic, they tend to use the same standards and assumptions they apply to themselves. They under-estimate the technologists’ activity level because outwardly, technologists appear more often to be what non-technologists would regard as “idle”—sitting at their desks, thinking, or typing [Schein 2016].

Last words

All of this shows how language, stereotypes, and assumptions conspire to lead  us to misallocate responsibility for creating technical debt. Some believe that technologists are solely responsible for technical debt, because only they can create it, and they aren’t working very hard to do anything about it. Proceeding from that conclusion, finding a resolution of the problem will be difficult indeed. Language, stereotypes, and assumptions can be traps.

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:

[Brenner 2005a] Richard Brenner. “Is It Blame or Is It Accountability?” Point Lookout 5:51, December 21, 2005.

Available here; Retrieved December 30, 2016.

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:

[Schein 2016] Edgar H. Schein. Organizational Culture and Leadership, Fifth Edition, San Francisco: Jossey-Bass, 2016.

Order from Amazon

Cited in:

Other posts in this thread

Show Buttons
Hide Buttons