CCD Red Degree Rule - The Boy Scout Rule

Writing clean code the first time just isn't enough. You have to work to maintain that cleanliness. The Boy Scouts of America have a rule that we can borrow and apply to software engineering. It says:

Leave the campground cleaner than you found it.

It is a simple enough concept. If you need to change some code, make sure you are changing it for the better. This does not need to be a difficult task. Change a variable name, extract a function. If you think the code could be expressed in a clearer, more straightforward manner then do it. Don't just passively perform this task, actively look at the code you are modifying and ask "Can this be better?". If yes, make it better. It's your duty as a professional.

If you've ever worked on a project for a year or two (I'm not convinced that it takes anywhere near this long) you'll know that the code slowly rots. It gets tangled up as people make modification after modification until eventually no-one will go near certain areas. These "scary forest" areas are inevitably the ones which clients want to make seemingly innocuous changes to and are then outraged when their request to "change it from green to blue everywhere" takes weeks.

Wait a minute, code is just zeroes and ones and they aren't degrading on my disk; why does code rot occur? I'm sure that there are lots of reasons but in my experience it usually happens because people are asked to make changes in code that they did not originally write. In their mind this is someone else's code. They are an intruder here so they had best make their change and get out quick.

And so they make their change without really understanding the best way to achieve what they need. They have taken the time to understand just enough to find one way to achieve their ends without considering what it does to readability and therefore maintainability. The next person to come along has a harder time. Their fear is greater. Their perception of  potentially better solutions is reduced. Their need to make the change quickly and get out increases and so the vicious cycle continues. Over time the original vision of the module becomes lost in a sea of quick fixes and kludges.

How can we stop this? Take the time to understand the code you are currently working on. Find a few ways of achieving the goal and then consider each one independent. Select the one that best aligns with the original vision of the module you are modifying and implement it. Encourage people to fix bugs in your code and offer to help fix bugs in theirs. You really want Collective Code Ownership but it can be hard to attain if the whole team aren't willing to try.

Above all, apply the Boy Scout Rule. Never check in code that is less readable/maintainable/clean than the code you checked out. Even if it wasn't your code (perhaps especially if it isn't your code. Sometimes people are just too close to see the mess they're making). If it takes you an hour to figure it out, clean it up. Then make your changes. Over time your code-base will improve in quality. It will be easier to understand and to explain to others.

One thing to be wary of is a developer who cowboys off into the source code making "improvements" at the expense of working on actual features. Unless you have enough time on your project to step back and consider this type of overhaul and plan it out in some detail I wouldn't recommend it. Changes need to be made in the face of existing requirements for the client to derive any kind of value. This sort of person is likely to accidentally break something right before a trade show demo and then get moved to another project for another client. If you have one of these people on your team, find some features that need to be implemented in a rough area to assign to them. It'll keep them out of the rest of the code-base.

Finally, be ever vigilant. The moment you stop actively applying the Boy Scout Rule is the very moment that your code-base begins to rot. It is a slow and subtle process and you probably won't notice it happening right away but the first new guy you add to the team sure will.

Posted by: Mike Minutillo
Last revised: 27 May, 2011 02:42 PM History


No comments yet. Be the first!

No new comments are allowed on this post.