Entropy Busters

I think I coined the phrase "entropy happens." My father has a degree in Physics. So I learned about entropy when he helped me with my elementary school science fair project. We took a cookie sheet of coins all face up. Then we flipped the coins all at once. I recorded the number of heads and tails. We continued flipping and recording for several iterations.


What a simple way to see that a system of order naturally moves to disorder when energy is applied! I didn't realize at the time but entropy also applies to life. As I grew older and wiser about the world, I observed life contains many examples of systems moving from order to disorder. Thus, I fashioned my geeky substitution for the well known phrase "s*** happens."

Signal vs. Noise youtubed a spot by Ira Glass. It reminded me that entropy also takes its toll on software. This can take many forms. 37signals has long highlighted feature bloat as one of entropy's victories. Developers know code bases also trend toward disorder.

These are just a few examples of disorder in code that come to mind:

• responsibilities of methods
• responsibilities of classes
• duplication of behavior
• high coupling
  

I want to guard against promoting refactorbation. I still don't know exactly how to find the right balance between prioritizing features vs. clean code. Sure, Nobody Cares What Your Code Looks Like, except other developers. But, I've inherited enough code sets to know that some degree of cleanliness in code is important. The priority is undoubtedly:

1. Features must solve pertinent business problems.
2. Code should be clean enough to be maintainable and extensible.

In both cases we are fighting entropy. Will you be an entropy buster?