How to Be an Effective Boy/Girl-Scout Engineer

Always leave the code better than you found it - it's that simple, yet not everyone is doing it. I've published this article last year and decided to republish it as there are some new lessons I learned on this topic and want to share.

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 whyand what we can do about it.

Lets 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 rulewhere 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 dont 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 itthis 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 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

The best way to do that is to use the use free Stepsize extensions for VSCode or JetBrains that integrate with Jira, Linear, Asana and other project management tools and will help you report and prioritise codebase problems directly in your editor.

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

What are the benefits?

Proponents of the boy-scout rule, like Robert C. Martin (Uncle Bob), are rightif 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 companysee 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 timeso don't despair and be prepared!