August 17, 2006
Factors in Code AgingI can't prove this yet, but I think software ages. If the arrow of time points in the direction of increasing entropy, then as software gets more complex that's how we know which way its clock is running. And as software gets more complex, it gets harder to maintain. Cost of maintenance should be an indicator of a system's effective age.
I blogged before about the code half-life, and this is no doubt a related phenomenon. Drink a pint of whiskey, smoke 80 Camels and eat nothing but pork pies every day and you'll age much, much faster than someone who drinks 2 litres of purified water, has never touched a cigarette and is a strict vegan.
The factors that we believe cause premature aging are well-known, but we still don't fully understand the causal link. Arguably, when things are complex enough, causality is impossible to determine empirically, and we have to learn to rely on statistical correlations instead.
Similarly, I'm unable to draw an empirical causal relationship between lack of test coverage and premature code aging. I can't prove that the former causes the latter. But there's a strong statistical correlation between low automated test coverage and code that's more difficult to maintain. So is it reasonable to conclude that test coverage is a factor in code aging? I think so.
And what about other factors? Well, module size and complexity are big factors in maintenance costs, and if we all agree that the harder code is to maintain, the "older" it is, then we could conclude that they are factors in code aging.
Module coupling and cohesion also seem to make a significant difference, as does the way modules are packaged into units of release/reuse (i.e., components).
How this helps my diet is anybody's guess?
Posted 15 years, 1 month ago on August 17, 2006