What is it?
During my time in the Scouts we would clear down our camp site in the same way each time. We would gather everyone in a big circle around the campfire and face outwards. The fire was the center of the camp.
We would then all walk outwards away from the fire up until the edge of the campsite. This boundary would be our personal site, not the full campsite we happened to be stopping in. Along the way if we noticed anything that wasn't right we would fix it there and then. This could involve picking up litter, closing gates, moving items out of the way and anything else. The idea was to put the area back to the way we found it. Then the next group to use the site would have the same experience as we did. Additionally this taught the younger scouts to look after their environment no matter where they are.
What is it in Software Development?
My personal experience of the "Boy Scout Rule" in software development came from the book Clean Code. This states that just like in the scouts we should aim to leave the codebase we are working with, in a better or equivalent state when we finish.
The misuse of this rule in software development is pretty rampant from my personal experience. Often this "rule" will be used to justify big sweeping changes. Alternatively I've seen changes occur under this "rule" in areas unrelated to the code being worked upon. This would be the real world equivalent of the Scouts leaving the boundary of the campsite or tackling tasks such as felling trees.
The misuse here is that the software development team is focused on one area, yet changes occur elsewhere meaning bugs or issues may be introduced. Such changes make reverts or rollbacks difficult. Not to mention adding to the noise that changes create such as peer reviews, discussions and testing.
The definition of better is also tricky. Refactoring can be highly subjective so when do you stop? In theory no code base is every complete, there will always be something someone would change if given the time.
Intent in Software Development
The intent of the "Boy Scout Rule" is good, however it is no rule. Don't get pressured into changes for the sake of change. All changes should be local to area you are already working in.
For example if you change a method of a type, then the method itself, the type and references of the method are fair game for refactoring or other improvements. The opposite of this would be making a change on the other side of the code base just because we can. The reason for this is every change introduces risk and has an associated cost.
In other words if you are already in the area of the code, refactor as needed. Leave that part of the codebase in a better state. Overtime these small changes will add up. Such hot spots in the codebase for change will become better in terms of quality. Any area that isn't subject to change probably isn't worth worrying about even if it is has glaring issues.
Increasingly as I gain more experience with software development I find the less code and the less changes made the better. I'm not claiming less lines of code is better - just small, isolated, well focus changes are. Likewise to apply a larger scale change just make lots of small changes in quick succession. These small changes should flow from local development to production.
The counter point to my case is how do we handle larger changes or architectural changes? In this case the "Boy Scout Rule" is inappropriate. Such changes should be planned, have a value associated with them and estimated. Only then should they be completed if really needed. Often what developers wish to produce is not in sync with the business actual wants or needs.