November 14, 2006

...Learn TDD with Codemanship

Code Tremors - Examples

A code tremor occurs when a change to one part of the software ripples through to other parts of the code. A code tremor might be small and localised. For example, renaming a local member variable might only force us to rename a couple of reference to that variable inside the same class.

Renaming a member variable causes us to have to change only two internal references - a small, localised code tremor

But changing the data type of a variable might have a wider impact.

Changing the data type of a member variable triggers changes in dependent classes - a larger non-localised code tremor

It's not hard to envisage a scenario where the impact of a change like the one above might cause us to have to make changes in many modules. In the case of birthday, the change is too complex to be handled by an automated refactoring, since a String and a Date can't be handled in the same way in most circumstances - that is to say, there are very few instances where String and Date are interchangeable.

Immediately we can see the dangers of things like global variables and widely-referenced Singletons. But there are more subtle dangers lurking in this model. And interesting questions? Should we always expect a change of data type to have a wider impact than renaming? Does the relationship between data types have any bearing on the relative scale of the code tremor? For example, would the impact be much smaller if we replaced an int with a String? (Or a SettlementAccount with a basic BankAccount?)

Certainly this is all rather suggestive of a kind of code mechanics that we might be able to apply to the measurement and study of the interconnectedness of code and the causes of code tremors. It may also lead us to a statistical understanding of what factors in software tend to increase the risk of larger code tremors.
Posted 14 years, 10 months ago on November 14, 2006