Software Entropy
The Second Law of Thermodynamics states that the entropy of any system will always increase as time progresses. Essentially, any isolated system's state will be disorganized and harder to maintain overtime. Take your house for example, it will become disorganized and unmaintainable unless you stop and clean it every so often. You are reducing the entropy of your house every time you clean. We've all seen the TV show called Hoarders, every person on that show has allowed their home's entropy to grow until it's unmanageable. Unfortunately, it usually takes a large team of professionals to make their house livable again.
Our software is not immune to entropy, and left unchecked, our code will eventually "rot" to the point where the team managing the codebase must eventually file for technical bankruptcy. This usually requires a complete rewrite because the codebase is no longer maintainable and it would be much easier to start from scratch then attempt to fix. There are a lot of reasons why software is allowed to "rot": sometimes there is a tight deadline or the culture at work has allowed bad code to slip through the cracks over a period of years. Whatever the reason, entropy will always win unless you take the time to correct the problem.
Broken Window Theory
Police officers and social psychologists have agree that if a broken window on a building is not repaired then there is a good chance the remaining windows will eventually be broken over time. A broken window usually signals that no one cares about the neighborhood and crime usually increases as a side effect. As a result, police departments have been trying to curb this problem by cracking down on small crimes that lead up to vandalism.
Philip Zimbardo, who is a Stanford psychologist, wrote a report in 1969 on some experiments he conducted testing the broken-window theory. He did this by abandoning a vehicle with its hood up in the Brox and within 10 minutes criminals were on the scene stripping valuable items from the vehicle or vandalized it until the vehicle was destroyed. A control vehicle was also abandoned in nice neighborhood in Palo Alto, California. This vehicle was left untouched for a week until Phillip smashed out a window with a hammer. After a couple hours vandals were on the scene destroying the vehicle and eventually turned it upside down. Phillip proved through empirical data that damaged property that's left to rot will eventually be destroyed by vandals regardless of neighborhood.
How to prevent
Don't allow broken windows and entropy to rot your codebase. Stop and clean-up dirty code when you can, or at least make an action item to fix at a later time. We've all been in a rush and needed to make a hard deadline but that's no excuse to forget about unacceptable code. Make it evident to management that you need to spend a couple days on the next sprint paying back the technical debt. Trust me, I've seen these type of things go unchecked for years… it always ends up in a code nightmare that requires a complete rewrite to payback the technical debt. Always be intentional about what you do and never Code by Coincidence.
Post Photo by Mark Vegera
Original Post from East Texas Software
Oldest comments (0)