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 classes. If you want the "absolute" version of the metric, just multiply it with Ce + Ca, but there's little value in comparing random classes across the project. Also, typically, you're not going to have a 100+100 case - and if you did, that should probably be redesigned.

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.

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.