Entropy is defined as "A measure of the disorder of a system."
While entropy got it's start in thermodynamics, it applies equally well to software development. Specifically late changes to the system design or bug fixing after a release.
Theoretically if you have a small system with only a few developers and you designed your architecture well, the initial version of a system is fairly clean. No nasty patches, no hacks to keep the thing limping along. Yeah right. Either way, the original development team has probably poured their guts also know as energy into the system to create order from disarray (like the socks in your drawer).
As additional releases with new features and patches are applied to the system entropy increases. The system starts to break down. The system requires more and more developer energy just to keep it going as the patches and new features take away from some of the original elegance. What's the smart developer to do?
I advocate that certain releases of a system introduce no new features, stop attempting to fix bugs and simply get the house in order. Allow modules to be rewritten taking into account all that has been learned since the original release. In short decrease the systems entropy again.
I like the way this is summarized by Frederick Brooks, JR in "The Mythical Man-Month"
..program building is an entropy--decreasing process hence inherently metastable. Program maintenance is an entropy increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.
Charles Angione
