Most engineers have heard of the 'boyscout 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.
The boyscout 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.
Why does it never work like this in practice, then?
What gets in the way of the boyscout 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 and instead bolt on yet more new code.
- 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 and continue to make more short-term contributions.
- The code's health keeps deteriorating until we have no option but 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 boyscout 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.
The boy/girl-scout engineer's release
To ship on time and spend my clean-up capacity on the most important things, I need to:
- Be aware of all the things I could clean up.
- Identify those things most worthy of my attention.
- Keep track of that list and attend to the top items, according to my capacity.
In effect, whenever they open their code editor, boy/girl-scout engineers need to clearly define their campground; they need to survey the landscape for potential things to clean up, rank them by order of importance, and keep track of their clean-up progress as they work towards shipping time. We built a free VSCode extension that does that for you!
Here's why being a boy/girl-scout is hard—and what you can do about it.
Scout engineers at high-growth software companies have it rough. The business grows and moves so fast that it can feel as if tech debt accumulates overnight. Well, that’s because it does.
Using the right tools and approach, engineers who care about code quality can identify the tech debt worth cleaning up—that's the tech debt that, once cleaned up, will move the needle on real business metrics like number of bugs, regressions, shipping cadence, user engagement, and more.
To be an effective boy/girl-scout engineer, you also need to learn about the laws of tech debt, the forms it can take, and how to fight it. We've investigated these extensively in our two-part series about the laws of technical debt, and in our article categorising different types of tech debt. Know thine enemy.
What are the benefits?
Proponents of the boyscout 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.
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!
Top comments (0)