Campgrounds and Codebases
The Boy Scouts of America have a rule, “Always leave the campground cleaner than you found it.” I was never a Boy Scout, but I found out about this rule when I read Bob Martin’s Clean Code. I thought it was such a splendid philosophy to apply to software engineering and codebases that I’ve probably referenced it a hundred times. Sure, it rolls off the tongue nicely, and teaches children to clean up after themselves, but I knew there was something subtle about it that I liked that wasn’t immediately apparent — something more fundamental, revolving around diligence, discipline, and dedication. It occurred to me that the underlying philosophy I was so attracted to was this revolutionary concept of giving a shit.
Imagine for a moment if your team rallied behind this unified vision of always leaving your codebase cleaner than when you opened it. How would that affect your approach? Would you think more about the changes you were about to make? I certainly did. I thought about how I felt about whomever had been here before me and had left this monolithic catastrophe. I also thought about the person who would spend some time here after me and who would have to clean up whatever mess I decided to leave behind. I thought twice, and I cleaned up. The Boy Scout Rule helps you think about the code you’re writing in terms of how it will affect the next person after you, and how it contributes to the system as a whole.
Most importantly, however, is that it encourages you to make small, incremental improvements. No improvement is too small. Extract an interface, pick up a bottle; introduce a factory, leave behind some firewood for the next troop. This approach to software makes the monumental task of refactoring a legacy system somehow possible. It makes the codebase everyone’s responsibility; if you spend time in it, you’re responsible for it. Someone may want to use the campground after you, so clean it up, ok? Every little bit helps.