Define and apply “The boy scout rule”

“The boy scout rule”, as defined by Robert C. Martin, tells us to make small improvements to existing code as we pass by implementing new features. It doesn't mean we need to make the whole class/file perfect, it just means we should make some small improvement in addition to the new feature, which of course should have a clean implementation. This is a good principle to include in the culture of any project. But how to do make it happen in a team with many developers, each bringing their own experiences and standards? In my project we are currently making a serious effort. Here are the actions we are taking. Please leave a comment with your own experiences/ideas.

First, talk about it. Introduce the name “The boy scout rule” - it is a quite funny name, and easy to remember. Load it further with the reference to real world scouts not caring who left the garbage found at the camping site, but always making sure the site is cleaned and left a bit better than found. Transfer the values into software development as a way to continuously refactor an existing code base while at the same time implementing new features.

Second, define, in concrete terms, what “The boy scout rule” means in the project. In our project we have made the following definition, with reference to our design principles:

• Increase readability
  • Choose intention revealing names from the business domain for classes/methods/attributes/parameters/variables.
  • Extract methods to enforce the principle of Command Query Separation (CQS) and intention revealing method names.
• Enhance the structure
  • Move methods to the“right” location to enforce the Single Responsibility Principle (SRP) for classes.
• Make it easier to do changes without introducing bugs:
  • Increase readability (as above).
  • Enhance the structure (as above).
  • Use domain objects for method parameters (e.g. use a ZipCode object instead of a simple String).

Third, lead by example. Start with the the informal leaders (often the most experienced developers) and have them spread the practice through interaction and pairing in daily work. Personally, when pairing with colleagues I try to explicitly point out what part of the work we are doing is implementing the new feature and what part is applying “The boy scout rule”. By doing so I hope to spread both the knowledge and practice to apply the rule in daily work.