Why the instability metric is a ratio?

Question

I've just started studying coupling metrics and I'm having a hard time understanding instability. I find the term quite misleading and I don't understand how it can really help me develop better software.

If I understand correctly, "instability" itself is not a bad thing: a package that is totally instable has no afferent connections and can change often without impacting other packages. On the other hand, it is particularly impacted by changes in its efferent packages.

But the point is, "How do I determine how much a package depends on others?" The given formula (Ce / (Ce + Ca)) does not make sense to me. Let's say I have an instability value of 0.5: I can have 1 efferent and 1 afferent connection (1 / (1 + 1)) but also 100 efferent and 100 afferent connections (100 / (100 + 100)). What does it mean that the instability is 0.5 in both cases?

In the case of 100 efferent connections instead of 1, I have many more chances that my package will break because I depend on many more packages. And with 100 afferent connections instead of 1, I have many more chances to break some other package that depends on my package.

Why seems to be usefult to know if a package is totally instable or totally stable, seems to me that any value between 0 and 1 does not give me a real sense of how much that code is coupled. I should have some "absolute" number, not something relative.

Am I wrong? Is there anything I'm not considering?

Update 24/11/2024

What confuses me is the apparent conflict between the common meaning of "instability" (changing often) and its meaning as a metric (depending on others). It seems that this metric measures the "desired" instability/stability, not the actual one. For instance, a domain package in a hexagonal architecture should have instability 0. However, even if I achieve this, it doesn't mean that it is truly stable! Ideally, I can change external adapters without impacting the domain, but if I'm in the early phase of a project or if my domain is evolving due to new business requirements, it will change often, breaking the external layers.

This situation is not ideal, but I wouldn't reverse the relationship (with the adapter being stable and the domain unstable) because it's the domain that dictates the changes to others, even if these changes happen frequently.

It seems to me that a more appropriate term could be propagability: how much a change in the component can propagate to others. This term does not suggest that the package is stable (not changing); rather, it indicates that if I change the package, I am willing to propagate those changes to its dependents.

Answer 1

Well, no metric is perfect. A metric is a relatively simple way to get a handle on some property of a complicated thing - for instability, think of it as of a normalized/relative metric (a value between 0 and 1, or alternatively, a percentage), that allows you to think in a more general way about the coupling structure of the package. It's a sort of a high level way to express the idea of instability regardless of package size/complexity, so that you can consider it within a context of a small group of collaborating modules/packages/classes. If you want the "absolute" version of the metric, just multiply it with Ce + Ca, but there's little value in comparing random software modules across the project.

What you want for a group of collaborating classes (or other software modules) is to organize the dependencies so that the less stable things depend on the more stable things. This is a property of a robust design. You want your abstractions (interfaces, base classes, core data structures, conventions used, etc.) to be relatively stable compared to anything that relies on them (this is expressed as the idealized "abstractness + instability = 1", and this is sort of what you're striving for). Otherwise the project becomes ... not fun, and the instability metric is one way to get a some kind of estimate or indication of this, to get a sense of where things are off in the design. In order to achieve an improved design, you might end up doing things like breaking some classes apart, extracting code into a utility class, introducing a new concept/data structure/interface, applying dependency inversion, moving the "guts" of components around to improve cohesion, etc.

The goal here is not to follow some abstract notion of "good design" but to make the code easier to work with, and better reflect what's actually going on in the domain. But it's a pretty simple metric that doesn't take anything about the domain into account, so it's not something to follow blindly. Your domain knowledge is going to play a role when it comes to actually achieving this, because what is going to be stable vs what isn't ultimately depends on the problem domain.

Answer 2

The thing to realise is that any given system has a fixed number of packages.

So the instability is just a measure of where a given package is in the dependency chain.

Root packages, say your Models, with no dependencies will have zero instability.

UI packages at the top of the stack will have no afferent, dependant packages and have all the other packages as efferent dependencies. and will have an instability of 1

middle packages with both dependants and dependencies will have an instability value which reflects how close the the root or top layer they are