Clean code and codebase entropy

Given enough time, no matter which best programming practices and design patterns were used, which coding standards were adhered to and how thoughtfully and elegantly code has been designed, the forces of entropy will still take their toll. Nothing is perfect. The moment will come when clean code is no longer clean code and needs to be adjusted, refactored or rethought. These moments - opportunities - probably occur more frequently than we think.

Researchers have discovered that in urban environments there is a triggering factor that escalates the speed of entropy. In one experiment, a car in good condition was left on the street for a week and remained untouched and in good repair until a window was broken. Within mere hours of the broken window, the entire car was stripped. Research has pointed in similar directions when it pertains to broken windows and dilapidated structures. Damage that remains unchecked for any period of time rapidly exacerbates the rate of decay which quickly goes beyond the point at which the investment for rehabilitation is so large that those with a vested interest would rather cut their losses than fix it.

The little things matter. A broken window apparently fosters a sense of abandonment and lack of regard which leads extraordinarily rapidly to further destruction. The broken window principle has been applied by police departments in various major cities with similar results: if you keep on top of the little things — fixing broken windows, cleaning graffiti, etc — there is a significant reduction in the number of major crimes.

Fighting entropy in code systems is a challenging and unending pursuit. Maintaining clean code is only the start but it might actually be one of the largest determining factors in keeping the effects of entropy at bay. Keep on top of the manageable things while they are still manageable and you will help stave off entropy. Not only will the code be better, the sense that how code is written doesn’t matter because “no one cares anyway” will be fended off. Repairing broken windows is a practice, a habit, a discipline.

When you stumble across broken windows in code, take action. Refactor, write tests, fix the problem and leave clean code behind. If there isn’t enough time to fix it properly, then at least leave a comment or even comment out the poor code when possible. Cultivate an environment that doesn’t foster the abandonment mentality.

I realize that in a world with business constraints, time constraints, and client demands, the push to settle often comes strongly and from the last place it should come from. Business concerns often win out. Just make it work. Now. Worry about clean code another day. Another day that never comes. It’s a constant balancing act between quality and efficiency.

In other words, I realize that excess time to improve code is often a luxury that’s hard to come by. However, there are countless opportunities presented to make improvements when we look for them. Make every opportunity of the “on-the-fly” moments. Utilize the opportunities that are presented when working on new functionality, bug fixes or other projects to repair broken windows and close the gap between the codebase you have and the codebase you want to have.

Related books:

 
134
Kudos
 
134
Kudos

Read this next

Open source community mentors: Thank you!

As a front-end developer, I’ve never had a mentor; at least not a face to face mentor. The closest I’ve had to a coding mentor was my ActionScript instructor, Liza Brown from Inkling, when I was in design school. Like many... Continue →