Untitled.Bat

Entropy refers the the amount of disorder in a system. In software systems, we generally mean software rot

Don’t live with broken windows

Some software systems have code which stays pristine, others tend to rot and decay. What makes the difference is the attitude by those working on the codebase. Researchers of crime statistics proposed a theory of broken windows which states that one broken window left for any substantial length of time instills in the inhabitants a sense of abandonment. This leads to another window getting broken, littering, graffiti and the sense of abandonment becomes a reality.

Don’t leave broken windows! If you can’t fix it, then board it up - comment out the offending code, or display a not-implemented message; Take some action to show that you’re on top of the problem.

When putting out fires, you want (in particular) that you’re careful about how to implement the fix as all it takes is one badly designed piece of code, a poor management decision or something similar to start the decline. It’s too easy for software teams to fall into the mindset of “all the rest of this code is crap, i’ll just follow suit”

Challenge
Can you tell when a window first gets broken? What is your reaction? If it was the result of someone else’s decision, or a management edict, what can you do about it?

A broken window isn’t always apparent. Sometimes a code smell creeps in during a large task where all parts of the system aren’t understood upfront. Driving out the implementation may lead to something functional, but could be complex and difficult to understand. The reaction should be to identify the smell however possible, and discuss the importance of fixing it. If the problem was a result of someone else, perhaps discussing the design approach taken and coming to a mutual understanding of why the design turned out that way, is required. This would at least promote education as to how it could have been done better.

The Pragmatic Programmer: CH1-2