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.
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.
If you use the materials on this page, or any other page on this web site, you do so at your own risk. They are provided "as is". No warranty is provided or implied. I neither guarantee that the materials will work, nor that they will not be harmful in any way.