Most engineers have heard of the 'boy-scout rule': 'Always leave the code better than you found it.' It's often been heralded as a magic cure for technical debt; if only all software engineers behaved like good citizens, our software wouldn't deteriorate so relentlessly.

But if it's that simple, why isn't everyone doing it, to curb tech debt once and for all?

You guessed it, it's not that simple. So let's figure out why—and what we can do about it.

Let’s look at:

• What makes it difficult for Engineers to follow this rule?
• How to make it easy for Engineers to be a boy/girl-scout?
• What strategy can help you clean up your code regularly?

The boy-scout rule—where does it come from anyway?

In 1941, the founder of the scouts,  Robert Stephenson Smyth Baden-Powell said, 'Try and leave this world a little better than you found it.' Over time, this may have morphed into, 'Always leave the campground cleaner than you found it,' but the sentiment is more-or-less the same. The point is that small but consistent efforts to keep the campground clean avoid a massive clean-up operation down the line.

Robert C. Martin (Uncle Bob) applied this rule to software engineering: 'Always leave the code better than you found it.' In other words, engineers should continuously clean up small pieces of tech debt so they never have to undertake a giant refactoring project when they're too close to technical bankruptcy. Simple enough.

What gets in the way of the boy-scout rule

Business pressures typically force engineers to bolt new code onto existing code, with limited time available for ensuring that the result is sane and maintainable.

This focus on short-term outcomes creates future productivity bottlenecks, or technical debt: code written yesterday that slows you down today.

A vicious cycle emerges:

• We want to ship quickly so we bolt on some new code.
• This makes future work more difficult, but we still want to ship quickly, so we don't take the time to clean up the code. 
• We also don’t have an easy way to create issues, flag the problem and add it to the sprint – and problematic code remains in the codebase.
• It becomes even harder to contribute productively to that part of the codebase, but the clean-up job is too big now, so we don't take care of it.
• The code's health keeps getting worse deteriorating until we have no option and we have to do a massive clean-up job to be able to keep shipping.

All of this is due to the false assumption that investing in software quality isn't worth the cost and will slow down the pace at which we ship. However, as Martin Fowler explains, this assumption is flawed, because clean code actually allows us to ship faster.

If you apply the boy-scout rule and leave the campground cleaner than you found it, you can break the cycle. But applying it in practice is not easy.

To see the problem more clearly, let's step into the shoes of a boy/girl-scout engineer for a moment.

The boy/girl-scout engineer's dilemma

I've been assigned a ticket. I've got to ship within a certain timeframe because I've committed to an estimate during planning. I'd like to achieve the goal and deliver business value on time, but I'd also like to leave my campground cleaner than I found it—this will make it easier for my colleagues and I to work on the code later, and the business will benefit because we'll be able to ship future work faster and it'll be of higher quality.

But how do I know how much cleaning capacity I have? How do I identify the things most worthy of my cleaning time? I can't clean up the company's entire codebase.

These are difficult questions to answer. My cleaning capacity will vary based on how quickly I can complete the new work, and identifying the few things most worthy of my cleaning time is difficult when there are so many options.

What actions might I take, given the above?

• I might over-clean and end up delaying the shipment.
• I might clean up a few things, but not the most important ones.

This is my dilemma.

3-steps strategy for making any code better

To avoid the situation where you need to stop all the development process to clean up your code, make sure your Engineering team follows these extended version of the boy/girl-scout rule:

1. If you see small tech debt / a codebase issue that can be fixed quickly → be a boy/girl-scout and fix it right away. Get yourself a piece of cake once done 🍰

2. If you see an issue that might take time to fix or you're unsure about → report and flag this issue in your editor

3. Track big issues continuously, prioritise them and add make them part of your sprint.

This way, you will always leave code better than you found it and have a healthy codebase.

AI and the boy/girl scout rule

In an evolving digital world where the boy-scout rule is vital for effective tech debt management, wouldn't it be great to have a virtual companion that supports this process?

I'm building Stepsize AI exactly for this, with my team.

Keeping track of every event across Slack, Jira, and GitHub, Stepsize AI provides engineers with rich summaries and insightful suggestions.

It’s like having a digital boy/girl-scout right by your side, keeping track of what is going on, contributing towards better decision-making and a faster, more efficient process.

Go and have a look at Stepsize AI, if you like

It’s got long term “memory” of your projects, too so it understands the context deeply. It’s not just a dumb layer between an LLM and your data.

It’s ultra-secure too. For example, your data never trains AI.

When you collaborate with Stepsize AI, you can create a software environment that improves over time, just as Robert C. Martin imagined.

What are the benefits?

Proponents of the boy-scout rule, like Robert C. Martin (Uncle Bob), are right—if followed consistently and applied properly, it will be your most effective tool in managing tech debt. We call it continuous tech debt management.

However, there is more to this rule than meets the eye and the tough bit is clearly consistency. Boy/girl-scout engineers need to learn about the laws and incentives that make it hard for them to be effective, but they also need to acquire the right tools and skills to really have a lasting impact on their codebases' health.

Code quality will speed up the whole engineering team, and therefore the entire company—see our piece about how tech debt affects everyone in the company.

Code quality is worth the cost.

In the words of Robert C. Martin, as captured in Kevlin Henney's book, 97 Things Every Programmer Should Know

"I think if we all followed that simple rule, we would see the end of the relentless deterioration of our software systems. Instead, our systems would gradually get better and better as they evolved. We would also see teams caring for the system as a whole, rather than just individuals caring for their own small part."

Being a boy/girl-scout might be tougher than you ever thought, but you can do it, and it will actually save you time—so don't despair and be prepared!