Stovepiping can lead to technical debt

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

Stovepiping can lead to technical debt. Actual stovepipes — the tubes that vent exhaust from stoves — serve as a metaphor for the flow of information in “stovepipe” organizations. In “stovepipe” organizations, information flows predominantly (or only) up or down along the parallel chains of command, and rarely (or never) from a point in one chain of command across to some other chain of command [Waters 2010]. The stovepipe metaphor is imperfect, in the sense that in actual stovepipes, smoke and fumes rarely flow downwards. By contrast, in organizations, some information does flow down the chains of command. But the metaphor does clarify the problem that whatever the organization learns in one metaphorical stovepipe isn’t easily transferred to other metaphorical stovepipes.

A wood-burning stove in a farm museum in Lower Bavaria (German: Niederbayern), which is one of the seven administrative regions of Bavaria, Germany. The stovepipe, which is the black tube running upwards from the stove, channels smoke and fumes out of the kitchen into the chimney, and then, presumably, out of the farmhouse.

Stovepiping can occur in both organizational structures and in engineered systems. These two forms of stovepiping are intimately related, and both can lead to uncontrolled formation of new technical debt, or increased persistence of existing technical debt.

In organizational structures, stovepiping occurs when similar capabilities are implemented in elements of two or more different organizational units that act relatively independently of each other. An example is the dispersal of some elements of the IT function out into IT’s customers. When independent organizations have similar technical needs, they’re at risk of independently implementing technological capabilities that duplicate each other, at least in some respects.

In engineering, stovepiping occurs, for example, when two or more technological assets are managed and maintained independently [McGovern 2003]. In that situation, distinct engineering efforts working on those assets might happen to solve the same problem, possibly in two different ways, with each party either ignorant, or possibly disparaging, of the other’s efforts.

In whichever way duplication of technological capability comes about, it can lead to increasing levels of technical debt, or to increased persistence of technical debt. This happens because the organization might be required to execute future maintenance or enhancement multiple times — once for each instance of the technical artifact. That exposes the organization to additional cost, additional load on its staff, and additional risk of creating defects and incurring liability, compared to a situation in which technical assets are shared among all who need them.

The problem is actually even more worrisome. First, in the case of a defect found in one version of a technological artifact, it’s possible that the people who are aware of the defect might not realize that another version of the artifact exists. If that other version also has an analogous defect, its defect might go unrecognized for some time, with all the usual attendant negative consequences. Second, in the case of a necessary extension of the artifact’s capabilities, the maintainers of one version might recognize the need for an extension, and implement it. Meanwhile the maintainers of other versions might not recognize the need for extension. They might not take action until something bad happens or a possibly urgent need arises. It’s easy to conjure other unfavorable — and costly — scenarios.

In engineering more generally, stovepiping can occur internally in systems, even though only one business unit is involved, and even though the stovepiped artifacts serve purposes invisible to the world outside the system. This can occur whenever communication is weak between the teams designing or maintaining the portions of the system that host the similar artifacts. For those familiar with the Apollo XIII incident, the incompatibility of the two carbon dioxide scrubbers in the command module and the lunar excursion module serves as an example of the risks of technical stovepiping.

When distinct business units or functions operate their own engineering or IT functions, or when they depend on a shared engineering function but require similar work, there is an elevated probability of duplication of technological assets or capabilities. This happens when the organizational structure, or the timing of the work, encourages separation of the engineering efforts. Engineering or IT functions operated separately under the control of distinct business units or functions can clearly produce duplicated capabilities. However, duplication can also occur when the engineering function is shared across distinct business units or functions, but the actual people and teams performing the work differ for different efforts, and when communication is weak between those teams. This can happen whether or not the efforts are conducted contemporaneously.

Because identifying these forms of technical debt after they’re created is notoriously difficult, preventing their formation is preferable to trying to detect them post-implementation. Prevention is possible if the enterprise establishes mechanisms that facilitate consultation and sharing among elements of different, separately operated technology development or maintenance functions. In other words, the organization must “break” the stovepipes — no mean feat, politically speaking.

Another challenge, of course, is providing resources for such sharing mechanisms, because preventing technical debt is rarely recognized as a value generator. If it were so recognized, the resources would likely appear. Changes in cost accounting might make such recognition more likely.

Contact me on social media:

Reference posts

A collection of definitions of terms as we use them in this blog, with links to longer discussions of each term. Along with each definition is a link to a post that discusses that term in more detail. Read more…

Welcome to Technical Debt for Policymakers. What you’ll find here are resources, insights, and conversations of interest to policymakers who are concerned with managing technical debt within their organizations. Read more…

When retiring one kind of technical debt from an asset, auxiliary technical debt is any other kind of technical debt in the asset. It can be tempting to try to retire auxiliary technical debt too. Sometimes that’s wise, but it can lead to scope creep. Rules of engagement can control this temptation. [More]

To retire technical debt, we need to know where it is. And if service disruptions are necessary, we need to know who will be affected. Here’s a survey of some of the issues, and suggestions for resolving them. [More]

For some assets, we can’t allow debt to persist, and we can’t afford replacements. We must retire the debt. This post begins exploring what it takes to design projects to retire technical debt in irreplaceable assets. [More]

By carefully observing what happens when we actually try to retire some kinds of technical debt, we can better understand the degree of the degree of wickedness of the effort. That understanding helps manage risk in technical debt retirement projects, reducing costs and speeding execution. [More]