Entropy in code
Last updated on August 13, 2010, 13:19 by Sebastian Mihai
The concept of entropy is very interesting, as it can be observed all around us everyday. It can have many definitions based on whom you ask. But in the end, they all describe the same property of "mixedupness" (Gibbs) of a given system. The higher the entropy of a system, the more chaotic, or mixed up it is.

The cool thing is that if left alone, systems of all sorts tend to increase their entropy. However, if energy is expended, entropy can remain the same or decrease, as long as there exists another system whose entropy will increase as a result.

The classical example given is that when molecules of gas are inserted in a closed space (a jar, for example), they spread out from the insertion point, taking up as much space as they can. They have become more chaotic as they travel all over the jar.

There are many other examples of entropy; a line-up of people entering a bus will sit as far apart from each other as possible. Released birthday balloons will not soar as a group, but will rather spread out. Ice will melt in a room, and then become gas (unless of course, energy is expended to keep the room cold, which would simply mean that the next room will become warmer because of the air conditioning or refrigerating unit).

A codebase (a product, or just a branch or trunk in a versioning system) will also tend to increase its entropy. In the absence of any special considerations for keeping entropy low, the codebase will become more chaotic, which can be observed through the scenarios below. Low entropy costs effort, and ultimately money.

Code Duplication
Assume you have a program that displays many screens throughout a session. As a result of a request, developer A will have to make it so that screen 4 shows some external content. Developer A modifies screen 4 to do so, and everyone is happy.

Everyone loves the new feature, and screen 1 is now about to receive the same feature. Developer B receives this task, and quickly copy/pastes the code from screen 4 to screen 1.

The next request has the feature ported to ten other screens. Developer C sees the code in both screen 1 and 4 and doesn't think twice about copying it to the ten new screens.

Having the same code on tens of screens after a few years does not seem unreasonable.

The Sea of Obsoletion
For as long as anyone can remember, feature A has used feature B, which in turn, has used features C and D. Someone determines that feature A should be significantly simpler, to the point where it does not require B anymore. The developer figures the only thing he needs to do is create a new entry point in feature A, which will never reach feature B.

Potentially, the codebase now has features and sub-features 'floating' around, rather than being tied down by entry points.


One of the most interesting bugs I ever fixed

Example of indexing and searching in Lucene.Net using C#

Atari Lynx - installing a power connector

Blood Bros arcade JAMMA PCB repair log (sound problems)


Listening to an electromagnetic field

Tesla coil - visualizing its electromagnetic field

.Net development - C# from C#

The naming convention of the C standards is Y2K-susceptible


Public constants across assemblies and default parameter values in C#

C# lambda operator

Simple two-column, three-panel web site template

An easy to use random number generator


(My) Useful settings for fresh Windows installations on new computers

How to use multiple versions of Firefox on the same computer

How indexes work

Trivialization of history through technology

Entropy in code

Basic Linux tricks

MSSQL tips for production databases

Keep your computer clean with VMware