I like to listen to podcasts on my walk to work and I try to interleave testing stuff with general science and technology. The other day a chap from Cambridge University was talking about entropy and, more particularly, the idea that the natural state of things is to drift towards disorder.
Entropy: “Historically, the concept of entropy evolved in order to explain why some processes (permitted by conservation laws) occur spontaneously while their time reversals (also permitted by conservation laws) do not; systems tend to progress in the direction of increasing entropy.”
In an ironic reversal of its naturally confused state, my brain spontaneously organised a couple of previously distinct notions (entropy in the natural world and the state of a code base) and started churning out ideas:
- Is the development of a piece of code over time an analogue of entropy in the universe? Could we say that as more commits are made, the codebase becomes more fragmented and any original order becomes slowly obscured?
- Is it possible that a metric based on entropy could be derived to measure the “organisedness” of a codebase, something like a cyclomatic complexity analysis? And, if so, could this metric predict software quality?
- Could there be strategies, perhaps again analogues of the natural world, for holding back the increasing entropy in the software?
- Could testing, with an aim of creating order at the external interface to an application, actually make the internal entropy worse by forcing more edits?
I strolled into the office feeling quite chuffed, made a cup of tea, turned my computer on, noted the 500 emails, ignored them, searched for “entropy testing” and found that, as usual, the good ship Original Thought had long since sailed. My day began its gradual decline into disorder.
Credit where it’s due:
- Software Entropy
- Entropy as a metric on the known disorder of the system
- Testing to reduce the entropy in an application
- Testing increases entropy
- Minimise the impact of testing on entropy