There’s a phrase everyone has already heard, in one form or another: “leave the code in a better state than you found it.” Behind this almost-too-simple formula hides one of the most powerful, and most neglected, levers for the longevity of a codebase. It’s the Boy Scout Rule, popularized by Robert C. Martin (Uncle Bob), and its value lies not in what it prescribes, but in the way it transforms a team’s relationship to quality.
Originally, the rule has nothing to do with code. Boy scouts had a principle of leaving a campsite cleaner than they found it: picking up a piece of litter that wasn’t theirs, putting a log back in place, properly putting out a fire. Transposed to software, this discipline becomes a hygiene routine that changes everything, precisely because it demands no heroism.
Capitalize on work in progress, don’t dedicate a project
The most widespread mistake is to think of code improvement as a separate effort: a slot you’d have to reserve, a task you’d have to plan, a “refactoring project” you’d have to sell to the roadmap. The Boy Scout Rule takes exactly the opposite stance.
The idea is not to dedicate time to an intensive, targeted improvement of certain parts of the code. The idea is to capitalize on the development needs already in progress and to introduce improvements as side effects of adding a feature. No more need to plan tasks or projects just to give yourself permission to maintain the codebase. You simply allow yourself the freedom, or rather you constrain yourself, to improve the related components and parts of the code you pass through while working on features that deliver value.
This nuance is decisive. As long as improvement remains a separate topic, it competes with the business, and it almost always loses. When it becomes a natural by-product of delivery, it stops being a trade-off and becomes a reflex.
The echo of Opportunistic Refactoring
This approach directly echoes the principle of Opportunistic Refactoring described by Martin Fowler: seizing every refactoring opportunity, however small, at the moment you already have the context in mind and the file in front of you. It’s precisely when you’re working on a piece of code that you understand its flaws best, and therefore when the cost of improving it is lowest. Postponing it means forcing yourself to reload all that context a second time, an effort that, more often than not, will never be made.
Make continuous improvement a non-event
The goal to reach comes down to a single idea: making continuous code improvement a non-event and a non-issue for your product teams, just as a Friday-evening production release should be. Not a debate, not a permission to ask for, not a line in a ticket. Just something that gets done, continuously, because it’s the normal way of working.
And by “improvement,” we mean something very broad, ranging from the simple to the complex:
- refactoring in the broad sense, or simply improving naming and documentation;
- the removal, update, or replacement of a dependency in light of new industry standards;
- the removal of dead code, which is no longer used but keeps consuming cognitive load;
- performance, algorithmic complexity, or better monitoring (logging, tracing, metrics).
None of these actions need to be spectacular. Their strength comes from their accumulation, not from their individual scale.
Why big improvements fail and small ones get through
Too often, I see targeted, purely technical improvements, carefully described in a backlog, and systematically postponed until they’re abandoned. They’ll always be judged less of a priority than business topics, and they’ll stay that way indefinitely, because an isolated technical improvement never finds a window where it outweighs a product request.
Small improvements, on the other hand, get through far more easily and generate infinitely less friction. They don’t call for a trade-off, don’t create a prioritization debate, don’t require justification. They slip into the existing workflow and, added together, produce a result that no “big refactoring project” ever reaches.
That’s the whole paradox: the most effective strategy for improving a codebase isn’t the one that aims big, but the one that aims small, everywhere, all the time.
A marathon, not a sprint
Improving code, or preserving its quality, is a marathon and not a sprint. You don’t save a codebase with a one-off, intense effort; you keep it healthy through a consistency that never wavers.
It’s therefore essential to adopt daily code-hygiene routines in the broad sense, to ensure the longevity of software and avoid watching the delivery pace slow down over time. A codebase never degrades all at once: it erodes through small, successive lapses, each one trivial. The Boy Scout Rule counters this erosion with an opposite force, also made of small gestures, but pointed in the right direction.
Adopting this discipline isn’t about adding yet another constraint to teams already under pressure. On the contrary, it’s about getting rid of a false dilemma: the one that pits value delivery against code maintenance. Properly understood, the scout’s rule reconciles the two. You ship, and in shipping, you leave behind a piece of ground a little cleaner than you found it.