I recently ran across an article that was talking (again) about the Object-Relational mismatch. And just like in many articles this mismatch is called the Object-Relational Impedance mismatch. This "impedance mismatch" label isn't just added when talking about object and relational databases, but pretty much in any situation where we have two concepts that don't match nicely:

• the XML/OO impedance mismatch
• noSQL/OO impedance mismatch
• document/OO impedance mismatch
• JSON Strongly typed language impedance mismatch
• Developer/Non developer impedance mismatch
• etc.

But what really is impedance mismatch? Impedance matching is something that comes from the world of electronics (or RF or audio):

"A technique of electric circuit design in which one component provides power to another, and the output circuit of the first component has the same impedance as the input circuit of the second component. Maximum power transfer is achieved when the impedances in both circuits are exactly the same. Impedance matching is important wherever power needs to be transmitted efficiently, as in the design of power lines, transformers, and signal-processing devices such as audio and computer circuits."

It comes down to the fact that power sources have their own internal resistance. Since we can't reduce the internal resistance to zero (unless you want to start playing with super conductors at -273 degree celcius). Because of this internal resistance some amount of power is wasted in the power source, instead of it all being transferred to the connected circuit (the load). If you look at the internal resistance and the resistance of the load in relation to the power that is lost in the generator we see the following:

In this figure you can see that we get the maximum amount of power transferred when the load resistance matches the resistance of the power source. More generalized this means matching the source impedance with the load impedance. We use the term impedance here. Impedance really isn't anything more than a more general term for resistance that also includes reactance. Impedance can be used for both AC and DC current, resistance doesn´t cover everything with regards to AC (but that's a different discussion).

But is this all good? If you look at the graph, we still loose half the power in the generator. Even if we get maximum transfer of power we're not really efficient. In practice what you see is that in power station the load resistance is set higher than that of the source to waste as little power as possible. The same goes when we're connecting speakers to an HIFI amp. In that scenario we usually have a very low resistance at the source and a higher resistance at the speaker (8 ohm). This will result in minimal power loss and still cause most of the power being transferred to the speaker.

There are however cases where impedance matching is a good idea. I won't go into the technical details but when you're dealing with high frequency signals, is that if you don't match up the impedance between source and load not all the energy is transferred to the load, but is reflected back along the cable to the source. Which can cause all kinds of problems.

So is it a badly chosen name, since in many cases having an impedance mismatch is actually a good thing?

Yes it is a very badly chosen name!

At least I think it is. In the way we use it impedance mismatch sounds like a bad thing. In electrical engineering it is just a property of an electronic circuit. In some circuits you might need to have impedance matching, in others you don't.

Saying we have an object relation impedance mismatch doesn't mean anything. Yes we have a problem between the OO world and the relation world, no discussion about that. Same goes for the other examples I gave in the beginning of this article. But labelling it with the "impedance mismatch" doesn't tell us anything about the kind of problem we have. We have a "concept mismatch", a "model mismatch", or a "technology mismatch".

I propose we start promoting the term "developer-manager impedance mismatch", where developers with minimal resistance from management can be the most efficient and get the most done!