Abstractness vs. Instability

We recently introduced NDepend static code analysis within some of our projects.
The report the tool is generating also contains a diagram called "Abstractness versus Instability" which perhaps needs some explanation.
But first, here is an example how it could look like:

 

Already in 1994, Robert C.Martin (author of "Clean code") wrote an article about a set of metrics that can be used to measure the quality of an object-oriented design in terms of the interdependence

between the subsystems of that design.

In general, dependencies should be avoided, but creating software systems completely without any dependencies is neither desirable nor useful.
What is important is the type of dependencies a component is depending upon - Martin distinguishes  between "bad" and "good" dependencies. Good dependencies are dependencies on "stable" components.
But what does a component qualify as being "stable"?
This can be expressed with a formula (see article mentioned above) that says:
a) stable components hardly depend on other components
b) many other components depend on them

The consequence of a) is that these components have no reason to change.
The consequence of b) is that there are a lot of reasons not to change these components.

Guess what "having no reason to change" and "lots of reasons not to change" in turn means? Well, these components simply won't change very often. Therefore they are considered as being stable.

Stable components could be imagined as the bricks of the bottom floors of a skyscraper. Imagine what has to be done if such bricks have to be replaced? All bricks on top of them have to be disassembled - for sure a lot of work to do.

The main sequence line in the above diagram shows the how abstractness and instability should be balanced. A stable component would be positioned on the left. If you check the main sequence you can see that such a component should be very abstract to be near the desirable line - on the other hand, if it's degree of abstraction is low, it is positioned in an area that is called the "zone of pain".
Why is this called "zone of pain"?
As mentioned above, these components have a lot of clients. This is a bad constellation together with the characteristic of low abstraction because "implementations" (i.e. low abstractions) tend to change frequently which means that (lots of) clients also have to be changed quite frequently. I guess most of us already faced components from the zone of pain ;-)

Now some words to instable components. Instable components are ones that depend on a considerable high number of other components.
Back to our comparison with skyscrapers: instable components are the bricks on the top floors. They are depending on bricks of lower floors (the stable ones).
Strive to reduce the number of components that depend on your instable components - only like this, they can be changed easiely without having to perform numerous changes within referencing components.