Quote of the week – analogies

Comparing to another activity is useful if it helps you formulate questions, it’s dangerous when you use it to justify answers.

Martin Fowler

I like analogies, probably more than I should. One of my favourite analogies is to compare code quality to the three different types of equilibrium I was taught in physics class.

Stable equilibrium is like a cherry in the bottom of a bowl. You can push the cherry slightly and it will return to its original position at the bottom of the bowl. It’s like well written code that can be changed without breaking in unexpected ways – perhaps the team followed the “Don’t Repeat Yourself” rule so that when a constant needed to be changed it was changed in one place and the change percolated correctly through the system.

Unstable equilibrium is when the bowl is overturned. With care you can balance the cherry on the top of the bowl, but the moment the cherry is disturbed it will roll off. I have seen lots of multithreaded code that was tweaked and tuned and hacked around until it “worked”. The moment anything changed, often something innocuous, the program would fall apart.

The third type of equilibrium is neutral equilibrium. Imagine that the bowl is filled with jelly (jello to our American readers) and the cherry is suspended inside the jelly. I think this proves a corollary to Martin Fowler’s original statement – you can only push an analogy so far before it breaks down (although if someone does manage to come up with a decent code analogy to neutral equilibrium I’d love to hear it).

5 thoughts on “Quote of the week – analogies

  1. Andy says:

    I would say the third form is code that has such a comprehensive test set that changing it will always break a test so you can be sure what new affects the code will have.

  2. Neutral equilibrium is when you edit the source code file, compile, deploy, but nothing changes. You’re missing something. Your change is not changing the deployed environment. Something is keeping it in equilibrium despite your actions. It could be a cache, you’re testing a different environment than you’re deploying to, some other code is stopping you from seeing the changes you’ve made, etc.

  3. Interesting analogy. I have a slightly different take on it though. Stable equilibrium makes it hard to change the object’s state (such as position), because when you change it the system applies a force to restore the previous equilibrium. For a piece of software I would say this is when it’s very difficult to make a change, because it applies a “force” that pushes you to put the program back the way it was (maybe in the form of falsely-failing unit tests and compiler errors). Unstable equilibrium is perhaps, as you say, when the a controlled change in the program cascades into more changes than intended, with no restoring force. Neutral equilibrium is exactly where you want to be: the force you apply to change the program behavior/state is proportional to the effect of the change, with nothing either trying to restore it to the previous state or reverberating the change to unwanted effects.

Leave a Reply

Your email address will not be published.