Boy Scout Rule and Its Limitations

| Practices

In programming, there is a practice called the Boy Scout Rule: leave the code cleaner than it was when you opened it. When working on a task, take a look around, and if there are any problems in the surrounding code, try to fix them. In commercial software development, this rule is considered controversial and not everyone likes it, but I believe it could be beneficial both for the team and for the code base if you take its limitations into account.

The rule is often disliked by process purists, because it by definition goes beyond a task scope and introduces code changes that have no immediate value for business (just like any refactoring). YMMV, but I've never had success with "refactoring stories" or "engineering tasks". They are usually a hard sell and don't get much enthusiasm from product owners, because they don't add immediate business value. Still, every long-living project accumulates technical debt over time, and it should be dealt with eventually. The notorious "fast-paced environment" that was mentioned in the last job opening you applied is not merely a figure of speech. Chances are, you're working in one. It means that you and your team don't always have time to make everything nice and clean. When there is time pressure (and there usually is) you have to take shortcuts, and it's better to deal with them _before_ they become a problem severe enough to account for a dedicated task. Boyscouting is one way to do that.

In addition to helping with the tech debt issue, boyscouting has some nice side effects:

  • Fosters the ownership mindset and craftsmanship

    One problem that occurs especially with junior devs is tunnel vision. They think about code only in the context of their assigned task and prefer not to touch surrounding code even if it's bad, either because they don't see any issues with it, are afraid to change it, or because it's not "their" code and they don't have the right to touch it. This is not a right mindset. While there are always team members that better understand certain parts of code (e.g. because they implemented it), code ownership and responsibility should be shared across the team. After introducing and encouraging boyscouting I noticed that my devs show more initiative in identifying and solving problems, and just generally better reason about code.

  • Helps preventing "broken windows syndrome"

    When the code base is sloppy, it tends to become sloppier over time. It's a signal that code quality is not an important metric and actually discourages cleaning things up, prioritizing churning new features as fast as possible instead. With boyscouting, code quality improves over time, and it sends a completely different message. "Code quality should improve over time" is actually a very powerful idea. As far as I know, it was first formalized in Google code review guidelines, a document that stirred the dev community quite a bit when it was released. Google guidelines are not for everyone, but there are a couple of nice bits I agree with, and the idea that the quality should improve over time is one of them. In practice it means that I'll accept a PR even if it (non-dramatically) exceeds the initial task scope, if the project will get to a better overall shape after the merge.

Refactoring A wonderful art of Kolja Wilcke that hits a bit too close to home

Limitations

  • Requires good Git discipline

    Ideally, every PR should be reviewable per-commit, and each commit should be self-contained and have a clear scope. In practice this doesn't always happen, and PRs could be difficult to review. Still OK if the PR is not too large.

  • Large refactoring still require a separate task with a separate time slot

    Boyscouting should be local and limited, and it's the responsibility both of an author and a reviewer to maintain a focused scope. It will not work for large and time-consuming refactorings, but will work just fine for smaller things such as code smells.

How many unrelated changes are too many? Depends on the team. This is roughly what we do in mine:

  • Code style changes (newlines, indents) - zero risk, close to zero value
  • Fix typos - close to zero (but not zero risk), modest value
  • Trivial refactorings, e.g. getting rid of nested if-else aka Pyramids of Doom
    --- Boy scout rule probably stops around this point
    • Simple refactorings, e.g. split a huge method within the scope of one class
    --- Some boy scouts roam here, but it's a danger zone
  • Everything bigger - needs a separate PR

Open source is a different story

Boyscouting issues are much less prominent when there are no time constraints. In open source development, for instance, refactorings are often encouraged.