Impedance and Software Delivery

Impedance is a term borrowed from the hard sciences and applied in a loose fashion to other domains. When we use terms in this way, like inertia, momentum, or velocity, they can provide a useful analogy or metaphor for an aspect of social sciences or other disciplines (possibly including software delivery) that helps explain a concept or principle. The problem is that people take these terms too far when they are used outside their intended context. Analogies and metaphors are useful only up to a point.

So, what’s impedance? According to the American Heritage Dictionary of the English Language, 4th edition, it means the following:

impedance n. A measure of the total opposition to current flow in an alternating current circuit, made up of two components, ohmic resistance and reactance, and usually represented in complex notation as Z = R + iX, where R is the ohmic resistance and X is the reactance.

n. An analogous measure of resistance to an alternating effect, as the resistance to vibration of the medium in sound transmission.

So, this is a metaphor for resistance to flow for some definition of “flow.” For software delivery processes, the metaphor is inherently weak as there is no correlation with the notion of an “alternating effect” such as vibration in sound transmission or alternating current in electricity. That said, the general notion of impediments to the steady flow of work is sensible enough that the metaphor can hold, provided one doesn’t try to read too much into it. Superficially the word “impediment” looks similar to the word “impedance,” but this does not give the words the same meaning.

Useful/meaningful example

Al Shalloway writes about a metric he calls Value Stream Impedance (www.netobjectives.com/blogs/introducing-value-stream-impedance-metric)).

The article proposes a method to quantify the “impedance” in a software delivery process. I think the metaphor holds well enough for this purpose, provided we remember it’s only a metaphor and not a real “thing.” However, I see a potential problem when we take a loose metaphor and give it undeserved substance by building a method or a set of calculations around it.

Thanks to the superficial impression of “importance” that people get when they see formulas and other sciency stuff, they’ll tend to think it’s a “thing” and grant the idea credence beyond the value of the metaphor. Of course, people might actually pay for something that looks sciency. There could be value in that for some participants in the free market.

But it isn’t a real “thing.” It’s only a metaphor. Yes, a software delivery process may be beset by various factors that interfere with continuous flow; but no, a software delivery process doesn’t have “impedance.”

Inappropriate/meaningless examples

In these examples, the authors appear to misapply the term impedance. The phrase impedance mismatch doesn’t have any obvious sense at all in the contexts of which the authors write, as far as I can tell.

Cultural Impedance Mismatch (www.agiledata.org/essays/culturalImpedanceMismatch.html)

This article discusses different perspectives and/or lack of information on the part of different groups of professionals, rather than any sort of “resistance to flow.” How can a culture have impedance? If a culture could have impedance, why should it matter that the impedance of one culture match the impedance of another culture? What would impedance mean in a “culture?” Resitance or reactance to…what? What is flowing? Electrical current? Culture currents, perhaps?

Agile Impedance Mismatch (technochord.com/2014/11/the-agile-impedance-mismatch/)

This article presents the idea that “agile” development methods have to be embedded in some sort of traditional project management structure. It isn’t my purpose to debate that point, but rather to make the observation that the word “impedance” (still less the phrase “impedance misatch”) simply has no meaning in this context.

Even if we take the word impedance to mean, in a general sense, “resistance to flow,” and we assume it is a reference to “the flow of work,” the analogy is still hard to see. There are two ways in which I have difficulty with the analogy in this context.

First, the implication seems to be that we should seek to equalize the impedance of the “agile” process and the traditional process. As there is no practical way to remove resistance from the traditional process, the only way to achieve equilibrium would be to slow down the “agile” process to match the traditional one. In that case, there’s no need to introduce “agile” at all; the organization already operates at the target rate of delivery.

Second, I question the assumption that equalizing the impedances will result in a desirable outcome. Let’s take the example of impedances in an amplifier and speaker. According to http://electronicdesign.com/communications/back-basics-impedance-matching-part-1, you get maximum power on the circuit by matching the load and source impedances. According to the article, “Maximum power is delivered when the speaker impedance matches the output impedance of the power amplifier. While this is theoretically correct, it turns out that the best arrangement is for the power amplifier impedance to be less than the speaker impedance.”

Bearing in mind this is only an analogy, if we consider the “agile process” to be the “source” and the “traditional process” to be the “load,” then we want the “resistance to flow” of the agile process to be lower than the “resistance to flow” of the traditional process, to obtain the best “sound quality.” That is naturally true; in fact, the article seems to be saying that this “mismatch” of impedances is a problem. But it isn’t a problem; it’s one of the main reasons we are interested in “agile” methods in the first place. Indeed, if “agile” had the same “impedance” as traditional methods, there would be no point in trying it.

Wrapping up

It’s entirely possible I have mis-read all three of these articles, and the respective authors were trying to make entirely different points. But the general impression I’m getting from all this talk of “impedance” is that it is at best a weak analogy for software delivery, and could be a distraction from more substantive matters, by causing people to worry about “impedance matching” in a context where the term has little (if any) meaning.