Boyscout Code
Published on JulĀ 20, 2017 (updated FebĀ 5, 2024), filed under development, quality (feed). (Share this on Mastodon orĀ Bluesky?)
[ā¦and girlscout code and any scout code:]
Still evaluating and normalizing feedback for the great maintainability survey Iāve so far worked through a ton of excellent comments. All of it will, in a comprehensive fashion, make for a new, updated web maintainability guide, and yet one particular aspect resonated so well with me that I wish to call it out again specifically: the boyscout approach to code.
This approach resurfaced after one of our peers commented the following on āWhat techniques do you find useful to keep websites maintainable?ā: āRefactoring every time you touch something and see potential for improvement.ā
Weāve probably all been there at some point, when we saw something and fixed it (a googley principle), and so I instantly nodded, āyes, thatās a great habit.ā It reminded of the boyscout credo, attributed to Robert Baden-Powell, to
Leave this world a little better than you found it.
or, more specifically,
Always leave the campground cleaner than you found it.
This does work so well for code thatāformerly (though certainly not unsurprisingly) unbeknownst to meāit had long been quoted by Robert Martin in, exactly, The Boy Scout Rule:
Always check a module in cleaner than when you checked it out.
ā¦which we could, and Iāve included this in my errata for The Little Book of Website Quality Control (updated), rephrase to simply say:
Always leave code better than you found it.
This is not new, either, but itās how Iād prefer to spell out the boyscout rule. Always leave code better than you found it.
As I said, thereās progress with the new, survey-inspired maintainability guide; stay tuned on Twitter on Mastodon or through one of this siteās feeds.
Update (August 21, 2021)
I like John Ousterhout here, writing the following in A Philosophy of Software Design:
Whenever you modify any code, try to find a way to improve the system design at least a little bit in the process. If youāre not making the design better, you are probably making it worse.
This makes the boyscout rule imperative rather than ānice to have.ā (It also asks for strategic and not tactical programming, but this is best explained in the book.)
About Me
Iām Jens (long: Jens Oliver Meiert), and Iām a web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, Iām an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for OāReilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)