Object-Oriented Tricks: #5 The Boy/Girl Scout Rule

Entropy

/ˈɛntrəpi/: lack of order or predictability; gradual decline into disorder.

Entropy in physics refers to the amount of “disorder” in a system. The laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum.

While the laws of physics don't apply to software, entropy hits it hard. When disorder increases in software, programmers call it software rot.

The Broken Window Theory

Software rot starts with one broken window.

One broken window, if left unrepaired for a substantial amount of time, instils a sense of abandonment. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.

The Boy Scout Rule

There are times when I have hacked together code because the entire component was somewhat hack-y. This only made the code worse than what it already was and made it tremendously difficult to change it later. In contrast, if you are working on a team/project where the code is cleanly written, well designed, and elegant; you will likely take extra care not to mess it up. Don't leave broken windows unrepaired. Fix each one as soon as it is discovered. Leave the code cleaner than you found it.

Dealing With Entropy

As Uncle Bob says, it's not enough to write code well, the code has to be kept clean over time. If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn't have to be something big. Change one variable name for the better, break up one function that's a little too large, eliminate one small bit of duplication, clean up one composite if statement.

Done And Gets Things Smart

Programmers are all smart and get things done but we should cultivate the habit of getting things done and making code smart.

You want someone who, when you give them a project to research, will come in on Monday and say: I'm Done, and by the way I improved the existing infrastructure while I was at it. Stevey's Blog Rants

TL;DR

You see evil and you destroy it. Always be refactoring. I've found that the following prioritization helps quite a lot:

bugs > refactoring > features

This applies to any programming paradigm, not just OOP. Andy Hunt and Dave Thomas have written about this extensively in their book The Pragmatic Programmer. Be sure to check it out and tell me your views.