Adiabatic Changes

In thermodynamics, we learn that most changes to a system are irreversible.  The entropy genie is let out of the bottle, and once out cannot be put back in.  Certain types of change, however, are reversible.  We call these changes adiabatic.

In an adiabatic change, the system neither gains nor loses heats to its surroundings, but I think that the concept applies nicely to software systems too.  Let's dig in a little bit and see how it works.

If we make large-scale changes to a complex software system -- especially a system that's being developed or maintained by a team of more than a handful of software engineers -- and those changes go wrong (i.e. the system fails its regression test suite), we must diagnose what went wrong.  Yes, if you are using a source code control system, you can simply back out all the changes that have been made until you restore the system to its last known good state.  I suppose in that sense, all software changes can be viewed as adiabatic.

But if you have multiple engineers involved, it is costly to back out everyone's changes and simply start over.  You could try backing out each engineer's changes one at a time.  We back out one set of changes and rerun the regression tests.  Does the system now pass?  If so, we might have a clue as to which changes caused the problem.

We might.

But what if it wasn't any particular engineer's changes that were at fault?  What if it was instead the interaction between changes that, taken individually were benign, but when taken together had a pathological effect?  Backing changes out one at a time, might not lead you to the right answer and might even mislead you.

On the other hand, if each change to the system is applied incrementally, we might be able to back the changes out without misleading ourselves.  So we emphasize incremental changes to complex systems. We emphasize incremental changes to local data structures. We emphasize changes that can be verified to have local effects.  We emphasize changes that due their incremental nature are reversible, adiabatic.

So we see that incremental changes to complex systems are easier to manage.  This is why I advocate phased development efforts. This is why agile methods work best (or at least easiest) on smaller projects involving fewer than 10 people: the changes are more often verifiable with regards to the propagation of their effects.  The changes do not cause the system to depart from its equilibrium (i.e. passing all regression tests) state.

Maintaining reliability thus becomes mostly a matter of sequencing a series of small changes and testing in between application of changes. While this cannot completely shield us from undesired interactions between changes, it will at least reduce their likelihood.  It will make most changes adiabatic.