A quick summary of the laws

• First Law (Conservation of Energy) Energy only changes form, its never created or destroyed. You can’t get more out than you put in.
• Second Law (Entropy) Heat flows hot to cold., Things get disorganised over time.
• Third Law (Absolute Zero) You can’t reach absolute zero. As temperature drops, entropy approaches a minimum, but zero K is unattainable.

Long after the 3 laws, a fourth law was prepended because its a foundation of the other three. 

• Zeroth Law (Equilibrium) If two things are each in balance with a third, they’re in balance with each other.

Translating this to software

Now lets get away from the raw physics, how does this relate to software?

Law Zero

In physics, the zeroth law is about temperature and equilibrium. Mathematically, it the principle of equivalence. If A=B and B=C, then A=C. When boiled down to a raw mathematical principle, its so obvious.

From a software point of view, the principle of equivalence is exercised for distribution, replication cacheing and authentication. As a simple example, if you download Concrete CMS version 9.4.7, you should get exactly the same code as everyone else that downloads Concrete CMS version 9.4.7. If it was not the same, then it would be breaking the principle of equivalence.

First Law

In physics, the first law is about conservation of energy. You can't create or destroy energy, only change its form. In a practical application, this usually gets mixed in with the second law about entropy. In any practical process you may think you are loosing energy, but that lost energy is actually transformed to heat.

In software, this relates closely with information. A system cant create information from nothing, any information it works with needs to be input. The destruction side of the analogy is where computer systems often fail. Anyone using a computer has managed to loose information. But we can apply the principle to system design, to design systems that can't loose information. For example, banking systems are designed so that an item of money is either in account A or account B. 

Third Law

We can't reach absolute zero in physics, and we cant reach a zero processing cost in software. We can write more efficient code. We can play algorithmic tricks to trade memory for processor cycles. But we can never do anything without using at least some memory, at least some processor cycles and taking at least some time.

Second Law

We are presenting this out of sequence because the second law is the important one. Heat flows from hot to cold and things get disorganised over time.

Suppose we start with a clean idea of a software system and start building it. As the system grows, ideas change, problems are resolved and the design is updated. But we don't go back to square one. Many of these changes involve compromises and convenience. Even before it is launched, the software has gathered some entropy.

Then through its life bugs are discovered and fixed. New capabilities are added. The underlying platform it runs on changes. External systems it communicates with change. These factors all increase the entropy of the software.

The key factor for developers is that we have some control over entropy. Whenever we make a change or add a new function, we can control how that is done. There will always be some entropy, but we can do things cleanly with structure, testing and documentation to minimise entropy, or we can do it messily, obscurely, or untested and introduce considerably more entropy.

Entropy in a software system escalates. The more entropy (disorganisation) a system already has, the harder it becomes to make further changes in a minimum entropy way. At some point the entropy reaches a point where any change introduces more bugs than it fixes. The system can no longer move forwards. It can be frozen for its existing use but is effectively end of life.

Thermodynamics is universal

Whilst a physicist would define these laws in terms of particles and energy levels, the principles apply universally. Historically, the laws of thermodynamics were formulated in one way or another before atoms and energy levels were discovered, then the modern formulation in terms of particles and energy levels was retrofitted. It shows that you don't need particles and energy levels to abstract anything in terms of thermodynamics.

We can abstract thermodynamics to help understand anything. For software, we can think of code as an arrangement of language elements, each is a particle. We can think of data as arrangements of bits - also an equivalent of a particle. Our language elements can be structured to give us working software, but over time these become disorganised. The same applies to our data. Two identical arrangements of code constructs fed identical data will have the same output. Code needs to execute to do actually do something. 

We may think of it as building and maintaining a web site. But behind the scenes it all boild down to thermodynamics.