Software Friction

I am surprised by discussions, so far. Which, at the moment appear to be people poking holes in the shortcomings of friction as a model, and then a few talking about the unreasonable effectiveness of some processes.

My surprise is that neither discussion really leans in on the metaphor. Friction, as a metaphor, is really strong as the way you deal with things vastly changes the more mature a technology is. Consider how much extra lubricant is necessary in early combustion engines compared to more modern electric motors.

More, as you cannot always hope to eliminate the external cause of friction, you can design around it in different ways. Either by controlling what parts of a system are more frequently replaced , or by eliminating the need for them entirely, if and when you can. You can trace the different parts of a modern car to see how this has progressed.

Indeed, the modern car is a wonderful exploration, as we had some technologies that came and went entirely to deal with operator involvement. Manual transmissions largely were replaced by automatic for a variety of reasons, not the least of which was wear and tear on the clutch. And it seems to be going away entirely due to the nature of electric motors being so different from combustion ones?

An electric motor is very different from an internal combustion engine. I'm not sure where you were going with the analogy but an electric motor does eliminate the need to lubricate that an internal combustion engine has (no valves, crankshaft, pistons, transmission etc.). Analogous somewhat to maybe a bad software architecture needing constant care vs. a better one that just works and eliminates a lot of that extra care.

I've learned about this term from the economics side rather than the military side. It's all the hidden factors that make things more expensive. Transaction costs. I do think this is a good analogy for "drag" in software development, something along the lines of "technical debt".