The Boy Scout Rule

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (10:51, 10 July 2009) (edit) (undo)
 
(7 intermediate revisions not shown.)
Line 1: Line 1:
-
The Boy Scouts have a rule. ''"Leave the campground cleaner than when you entered it."'' What if we followed this rule with our code? What if we always checked in the code cleaner than when we checked it out. If we did that then the software would get cleaner and cleaner over time. It wouldn't rot, and grow ever more tangled. Given that bad code slows us down so horribly, don't you think that following the boyscout rule is simply a matter of common decency?
+
The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try and leave this world a little better than you found it."
-
When was the last time you were significantly impeded by bad code? It was probably recently. What do we do to prevent bad code from slowing us down in the future? We clean it.
+
What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out." No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result?
-
Every time you check a module out, do some small bit of refactoring to clean that module so that it's better than when you checked it out. It doesn't matter how much cleaning you do, so long as you utterly refuse to check in a module any worse t when it was checked out. If you, and everyeone else on the team simply make a series of small improvements without making worse messes, then over time the system will be very clean.
+
I think if we all followed that simple rule, we'd see the end of the relentless deterioration of our software systems. Instead, our systems would gradually get better and better as they evolved. We'd also see ''teams'' caring for the system as a whole, rather than just individuals caring for their own small little part.
 +
 
 +
I don't think this rule is too much to ask. You don't have to make every module perfect before you check it in. You simply have to make it a ''little bit better'' than when you checked it out. Of course, this means that any code you ''add'' to a module must be clean. It also means that you clean up at least one other thing before you check the module back in. You might simply improve the name of one variable, or split one long function into two smaller functions. You might break a circular dependency, or add an interface to decouple policy from detail.
 +
 
 +
Frankly, this just sounds like common decency to me &mdash; like washing your hands after you use the restroom, or putting your trash in the bin instead of dropping it on the floor. Indeed the act of leaving a mess in the code should be as socially unacceptable as ''littering''. It should be something that <i>just isn't done</i>.
 +
 
 +
But it's more than that. Caring for our own code is one thing. Caring for the ''team's'' code is quite another. Teams help each other, and clean up after each other. They follow the Boy Scout rule because it's good for everyone, not just good for themselves.
by [[Uncle Bob]]
by [[Uncle Bob]]

Current revision

The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try and leave this world a little better than you found it."

What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out." No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result?

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

I don't think this rule is too much to ask. You don't have to make every module perfect before you check it in. You simply have to make it a little bit better than when you checked it out. Of course, this means that any code you add to a module must be clean. It also means that you clean up at least one other thing before you check the module back in. You might simply improve the name of one variable, or split one long function into two smaller functions. You might break a circular dependency, or add an interface to decouple policy from detail.

Frankly, this just sounds like common decency to me — like washing your hands after you use the restroom, or putting your trash in the bin instead of dropping it on the floor. Indeed the act of leaving a mess in the code should be as socially unacceptable as littering. It should be something that just isn't done.

But it's more than that. Caring for our own code is one thing. Caring for the team's code is quite another. Teams help each other, and clean up after each other. They follow the Boy Scout rule because it's good for everyone, not just good for themselves.

by Uncle Bob

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools