December 7, 2007
Unified Principles of Dependency Management & An Explanation of the Value of High Test CoverageThe story so far...
A long time ago, in a galaxy far, far away, I theorised that it might be possible to unify the principles of dependency management so that they can be consistently applied at all levels of code organisation: methods, classes, packages, systems, systems of systems, and so on.
The ripple effect, where a change to one part of the code "ripples" out to other dependent parts of the code, appears to have self-similar mechanics at method, class and package level, if my thought experiements, simulations and general knowledge and experience are to be believed (which is, I admit, a bit of a stretch usually).
Ripples in code spread like fires through the trees in a forest. How we localise those fires can explain much about how we localise code ripples
The techniques we can apply to localise ripples in our code also appear to be self-similar at different levels of organisation. Cohesion and coupling of methods, classes and packages, for example, are almost certainly factors in an equation that appears to work ubiquitously at all levels. Size and complexity are another factor: long methods, long classes and large packages tend to lead to bigger ripples, because we have units that are more likely to change, and more likely to spread change because they are more interconnected. Finally, there is also the question of which direction our dependencies go in: towards or away from units of code that are less likely to change. (The current received wisdom is that abstractions are less likely to change, but I suggest its a bit more complicated than that. Is an interface with 20 methods really less likely to change than a concrete class containing 3 lines of executable code? I suspect not.)
I wouldn't be at all suprised to find that the ripple effect is just as prevelant in enterprise architecture, where changes to one system ripples out to other dependent systems. Service-Oriented Architects should probably take note: coupling, cohesion and the direction the dependencies go in all probably play a role in at this level, too.
This offers up the possibility of a set of unified principles, practices and metrics that can be applied at any level, replacing the exisitng set of rather hotch-potch conceptual tools we currently apply. (Well, some of us currently apply them, anyway.)
At the very least, it might make explaining dependency management a whole heap easier, and that might mean that more people actually get it. Which would be nice, especially if it means that more code ends up costing less to change.
Mr T is a fan of good dependency management practices. Probably.
Finally, I now realise the very close relationship between dependency management and test assurance. It's not only changes that propagate along dependencies. Bugs also propagate. When I change on line of code, I can end up breaking line of code that depended on it. Here we're talking about semantic coupling, which can be very far reaching. That gives me a strong statistical argument for having high test assurance.
Imagine in our code some modules are covered effectively by tests, so if they break, the tests will fail and we will be quickly alerted. Other modules have no test coverage, so if a bug propagates to them, it goes undetected for longer - maybe escaping into a production release.
A mountain of industry data proves beyond reasonable doubt that bugs cost exponentially more to fix the later they're detected. So here we now have the actual mechanism that explains why high unit test coverage saves you time and money - and it's another ripple effect, like my forest fire analogy.
This model helps me to build a strong business case for test coverage and dependency manamagement that even a project manager could probably understand. Maybe.
Posted 12 years, 11 months ago on December 7, 2007