The Boy Scout Rule - Revision history

Kevlin at 10:51, 10 July 2009

Kevlin — Fri, 10 Jul 2009 10:51:27 GMT

←Older revision		Revision as of 10:51, 10 July 2009
Line 7:		Line 7:
	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.		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 <i>just isn't done</i>.	+	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 <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.		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.

Unclebob at 17:24, 18 February 2009

Unclebob — Wed, 18 Feb 2009 17:24:03 GMT

←Older revision		Revision as of 17:24, 18 February 2009
Line 7:		Line 7:
	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.		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.	+	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 <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.		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.

Kevlin: The Boyscout Rule moved to The Boy Scout Rule

Kevlin — Fri, 05 Dec 2008 06:27:35 GMT

The Boyscout Rule moved to The Boy Scout Rule

←Older revision

Revision as of 06:27, 5 December 2008

Kevlin at 06:19, 5 December 2008

Kevlin — Fri, 05 Dec 2008 06:19:27 GMT

←Older revision		Revision as of 06:19, 5 December 2008
Line 1:		Line 1:
-	In [[You gotta care about the code]] Pete Goodliffe made the point that "good programmers write good code" because they care. Well said. However, there's more to it than that. Good ''teams'' write good ''systems'' because they care about the quality of that system.
-
	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."		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?		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 for their own small little part.	+	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 ~~(see [[Small!]])~~. You might break a circular dependency, or add an interface to decouple policy from detail.	+	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.		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 ~~boyscout~~ rule because it's good for everyone, not just good for themselves.	+	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]]

Unclebob at 14:04, 26 November 2008

Unclebob — Wed, 26 Nov 2008 14:04:34 GMT

←Older revision		Revision as of 14:04, 26 November 2008
Line 7:		Line 7:
	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 for their own small little part.		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 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 (see [[Small!]]. You might break a circular dependency, or add an interface to decouple policy from detail.	+	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 (see [[Small!]]). 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.		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.

Unclebob at 14:04, 26 November 2008

Unclebob — Wed, 26 Nov 2008 14:04:00 GMT

←Older revision		Revision as of 14:04, 26 November 2008
Line 1:		Line 1:
-	~~The Boy Scouts have a rule: "Always leave~~ the ~~campground cleaner 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~~.~~" What would be~~ the ~~result?~~	+	In [[You gotta care about the code]] Pete Goodliffe made the point that "good programmers write good code" because they care. Well said. However, there's more to it than that. Good ''teams'' write good ''systems'' because they care about the quality of that system.

-	~~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~~.	+	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."

-	~~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.~~	+	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?

-	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 as should be as socially unacceptable as ''littering''. It should be something that just isn't done.	+	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 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 (see [[Small!]]. 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 boyscout rule because it's good for everyone, not just good for themselves.

	by [[Uncle Bob]]		by [[Uncle Bob]]

Kevlin at 17:42, 24 November 2008

Kevlin — Mon, 24 Nov 2008 17:42:26 GMT

←Older revision		Revision as of 17:42, 24 November 2008
Line 1:		Line 1:
-	The Boy Scouts have a rule: "Always leave the campground cleaner 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."? What would be the result?	+	The Boy Scouts have a rule: "Always leave the campground cleaner 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." 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.		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.

-	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.	+	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.

-	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 as should be as socially unacceptable as ''littering''. It should be something that just isn't done.	+	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 as should be as socially unacceptable as ''littering''. It should be something that just isn't done.

	by [[Uncle Bob]]		by [[Uncle Bob]]

Unclebob at 10:56, 20 November 2008

Unclebob — Thu, 20 Nov 2008 10:56:43 GMT

←Older revision		Revision as of 10:56, 20 November 2008
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." What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out."? What would be the result?

-	~~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~~.	+	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.

-	~~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 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.
		+
		+	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 as should be as socially unacceptable as ''littering''. It should be something that just isn't done.

	by [[Uncle Bob]]		by [[Uncle Bob]]

Unclebob at 23:36, 19 November 2008

Unclebob — Wed, 19 Nov 2008 23:36:16 GMT

←Older revision		Revision as of 23:36, 19 November 2008
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?

		+	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.

		+	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.

	by [[Uncle Bob]]		by [[Uncle Bob]]

Unclebob: New page: by Uncle Bob This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] Back to 97 Things Every Programmer Should Know hom...

Unclebob — Wed, 19 Nov 2008 23:14:01 GMT

New page: by Uncle Bob This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] Back to 97 Things Every Programmer Should Know hom...

New page

by [[Uncle Bob]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Programmer Should Know]] home page