September 11, 2007
Dependency Management - A Thought ExperimentHo hum. Back again with the forest fires.
Imagine a wierd kind of forest where all the trees are in bubbles, and each bubble can be connected to other trees via a pipe that allows air to flow between the two bubbles, but in one direction only. At the top of each bubble there is a hole, and we randomly drop a burning match into the hole of one bubble, setting fire to the tree within. When a tree burns, there's a 50% probability that the fire will spread through a tube connected to another tree's bubble and set fire to that tree, allowing the fire to spread from tree to tree - potentially to the entire forest. But it can only spread in the direction that the pipe allows air to travel.
No, it's not Center Parcs. It's my new thought experiment, designed to help me understand the whole dependency management thingummydoodah.
The trees represent types in a software system. The pipes represent dependencies between types. Fire represents change, and when fire spreads through a pipe to another tree, that represents change propogation between types in our system.
I am already obsessed with two questions that my model raises:
Firstly, Given a particular network of trees, can we calculate the number of trees we would expect - in the probability sense of the word - to burn when we drop a random match? Can we look at the properties of the network - its topology, if you like - and estimate how far a fire is likely to spread through it? Or could we calculate across all of the trees the match might land on, and across a range of extents of forest fires, a probability distribution for that network's flammability?
Secondly, what if a match was more likely to land on some trees than on others- perhaps by making the holes at the top of their bubbles larger? (In software terms, what if some types were more likely to change than others?) How could we arrange our pipes so that our forest was less flammable - i.e., fires would tend to spread less far?
Would this forest be more flammable or less flammable than the first example?
In software design, we argue that abstractions are less likely to change (less likely to have a match dropped on them if they were trees). And we also argue that dependencies should tend to go towards abstractions. Change propogates backwards along dependencies. If A depends on B, then a change to B can propogate back to A, but not vice-versa. The direction of airflow in the pipes represents the direction of change propogation in code, so we would design our forest so that air was being pumped away from the trees where matches are least likely to fall.
In software, change propogates backwards along dependencies from supplier to client
The big question is, does this really minimise the flammability of the forest? Anecdotally, I "know" that it's better to depend on abstractions. But I can't prove it. Indeed, I'm not even aware of any compelling industry data on this topic. So it's all hearsay to this point.
Another big question is whether code abstractions really are less likely to change. Again, I don't know of any data that might inform us.
I'm still working this idea through, but I reckon I'm getting closer to some useful insights. I think maybe a new metric or two might fall out of this, too. And I know how much you all love metrics...
In the meantime, if anything jumps out at you while you're pondering this problem, please drop me a line - I need all the help I can get!
Posted 10 years, 10 months ago on September 11, 2007