Dependency Inversion & Reducing Expensive Variability

While working my way through Donald G. Reinertsens latest book, The Principles of Product Development Flow, I noticed that one of his principles for exploiting variability is “V14: Substitute cheap variability for expensive variability.” The basic idea is that during product development you should be aware when you can sacrifice variability with a low economic impact to reduce more expensive variation.

This reminded me of a more common principle in software development, the Dependency Inversion Principle (DIP). The DIP specifies that higher level modules should depend on lower level ones and that both should depend on abstractions, rather than specific implementation details. But why is this the case? What benefit does this bring?

Most experienced developers understand that one of the ways to make your code base as stable and as resistant to the effects of change as possible is to progressively stack your software into layers. Dependencies between the layers should flow from the higher layers to the lower layers. The lower the layer, the more stable and static the code in that layer should be. The opposite is true for code in the higher layer. Thus the higher layers contain the most dynamic code and the code most likely the change. Since the second part of the DIP specifies that you should depend on abstractions and not details, it follows that your lower layers should house your application abstractions and that those abstractions should remain fairly static.

Because of these dependencies, the economic cost in changing that code is inversely proportional to layer in which that code is found. The lower the layer, the higher the cost and vice versa. Using V14 above, you can make architectural decisions about where changes to your code base should happen if you can quantify the amount of variability the change is likely to introduce.