October 1, 2007

...Learn TDD with Codemanship

Change Propagation Simulation

I've been cobbling together a simple simulation - at least, it seemed simple when I started it last week - to explore how change propagates along dependencies, and whether the extent to which dependencies go towards types that are less likely to change has any bearing on the probable extent of the ripple effect we might expect when we randomly change one type in the system.

I'm using a model of a system made up of types, each type having a relative probability of change of either 0.5 or 1. In other words, when we randomly drop a change in to our system, it is twice as likely to land on a type with probability 1 than on one with probability 0.5.

In my simulation, I used systems containing 100 randomly generated types.

Each system has 200 randomly generated dependencies, each dependency has a client type and a supplier type. In the illustration, the supplier is at the end of the dependency where the arrowhead points.

I then did some noodling such that, across 1000 such randomly generated systems, the probability that a supplier will have a 0.5 probability of change is gradually increased until it is certain that every dependency will go towards one of these types that are half as likely to change.

With me so far? Thought not. Not to worry - I'm still grappling with it myself.

Anyway, the game is afoot. For each of the 100 randomly generated type systems, one type is selected for change. For example, in a system where every type has a probability of change of 1, then any one of 100 types has a 1% probability of being selected.

When that selected type is changed, there is a 50% probability that the change will propagate to one of the types that is depending on it (one of its clients, in other words). In this way, change can ripple outwards from the epicentre, in much the same way that fire can spread through a forest from one tree to its neighbours.

In programming terms, this means that making a change to one module in our software could require us to change other dependent modules.

The $64,000 question is: will change tend to propagate less far in systems where types tend to depend on other types that are less likely to change than they are?

The results are in, and the answer appears to be YES.

Out of 1000 simulated type systems, with a gradually increasing proportion of dependencies on types that have a 0.5 relative probability of change, larger ripples become rarer as this proportion goes up.

Why one type might be less likely to change than another is a different question, and one that needs asking urgently. I am unconvinced that the conventional OO wisdom of "abstract = less likely to change" is necessarily true. I think there's more to it than that. It certainly needs some thought.

Naturally, as we would expect, large ripples are rare. I wouldn't be at all surprised to see a power distribution, with the occurences getting exponentially less frequent as the size of the ripple increases.

A quick noodle with Excel suggests that this is may indeed be the case.

But even so, with just 1000 data points (and in any project we can expect to make more than 1000 changes during the software's lifetime), large ripples are not as rare as we might wish.

The simulation gives a strong indication that one of our design principles is more than just hearsay, though.

Next up - I'll be testing package design principles and metrics using a modified simulation. Bet you can't wait
Posted 10 years, 7 months ago on October 1, 2007