October 22, 2007

...Learn TDD with Codemanship

Dependency Management & Relative Cost of Change

One of the temporary upsides of having your widescreen TV stolen is that you are forced to find more worthwhile pastimes to amuse yourself.

I noodled around on paper with the simulation I was using before to experiment with the effects of different kinds of coupling strategies in randomly generated type systems. This time, the question I wanted answered was: what is the average extent of change propagation (and therefore the average relative cost of change) as a function of the percentage of dependencies on types that are less likely to change? (I might get a t-shirt printed with that catchy slogan...)


In the original simulation, a directed graph of types with relative probability of change of 1 or 0.5 is randomly generated. A single change was dropped on one of the types, (being twice as likely to drop onto a type with probability of change of 1), and this change had a 0.5 probability of propagating to any other types that directly depends on it

Given that there is a power distribution that applies to propagation extent, with types systems where larger numbers of types were changed being exponentially rarer, I was half expecting to see relatively modest increases in change propagation as the percentage of couplings to types that are less likely to change decreased.

This morning I had 15 minutes to kill at work waiting for a meeting, so I quickly fiddled with the simulation code and produced an output that demonstrates a much more striking relationship between the two variables:



According to the simulation - and this is just a simulation, so please take it with a small pinch of salt - a type system where 60% of dependencies are on less likely to change types (boy, I've really got to find a quicker way to explain that) has an average extent of change propagation that is roughly half that of a system where only 30% of dependencies are on less likely to change types. We might expect, therefore, that the cost of change in the latter might be roughly twice as high. And that's quite a big deal.

I was expecting maybe a difference of 10-20%, meaning that if you invested 10-20% of your time refactoring to minimise change propagation, it would pay for itself. Now I'm thinking you could spend 50% of your time on it and still break even.

That's a gross oversimplification, of course. Which is just how I like it...
Posted 13 years, 1 month ago on October 22, 2007