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. 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. Robert C. Martin (Uncle Bob) 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, , this assumption is flawed, because clean code actually allows us to ship faster. as Martin Fowler explains 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 clean up. could 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 and , 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. right tools approach 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 , and . Know thine enemy. the laws of technical debt in our article categorising different types of tech debt What are the benefits? Proponents of the boyscout rule, like , are right—if followed consistently and applied properly, it will be your most effective tool in managing tech debt. We call it . Robert C. Martin (Uncle Bob) continuous tech debt management However, there is more to this rule than meets the eye and the tough bit is clearly . 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. consistency 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 —so don't despair and be prepared! save you time

Different

Keep

Track and prioritise technical debt. Create your free account at stepsize.com

2022 - HackerNoon Contributor of the Year - Code Quality

2022 - HackerNoon Contributor of the Year - Coding

2022 - HackerNoon Contributor of the Year - Frontend

2022 - HackerNoon Contributor of the Year - Refactoring

Get the AI companion for software projects. Never miscommunicate again

Nominated for 2022 - HackerNoon Contributor of the Year - Frontend

Nominated for 2022 - HackerNoon Contributor of the Year - Code Quality

Nominated for 2022 - HackerNoon Contributor of the Year - Coding

Nominated for 2022 - HackerNoon Contributor of the Year - Refactoring

Too Long; Didn't Read

Making security fun one episode at a time

Always Leave the Code Better than You Found It - Boy Scout Engineering 101

Always Leave the Code Better than You Found It - Boy Scout Engineering 101

Too Long; Didn't Read

Companies Mentioned

Alex Omeyer

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Always Leave the Code Better than You Found It - Boy Scout Engineering 101

Too Long; Didn't Read

Companies Mentioned

Alex Omeyer

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES