Caring For The Code
Monday, March 29, 2010 at 10:24PM I recently picked up the new book 97 Things Every Programmer Should Know edited by Kevlin Henney and published by O'Reilly.
In the currently-fashionable ADHD-afflicted style, It's a collection of 97 short essays on computer programming. I gently mock the concept but books laid out in this way are absolutely perfect for reading on an iPhone.
Anyway, I'm about a quarter of the way through and enjoying it a lot. The stand-out essay in the first quarter is by Robert C. Martin, entitled "The Boy Scout Rule". Here's an excerpt:
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 it. You intentionally improve the environment for the next group of campers.
What if we followed a similar rule in our code: “Always check a module in cleaner than when you checked it out”? Regardless of 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 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.
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 really like this idea a lot. I've heard Wil Shipley articulate it as "clean as you go" - if you see something messy, fix it then and there.
You should definitely check out 97 Things Every Programmer Should Know. I bought it as a DRM-free ePub from O'Reilly (with the buy-one-get-one-free coupon code "BYGET" - don't know how long that's valid for). It reads just perfectly in Stanza on the iPhone.
Reader Comments (3)
A 'clean as you go' policy in a multi-developer environment does mandate good code coverage in your regression tests though. It can also blur the lines between the changes that were required for a defect fix vs the cosmetic changes that were delivered alongside.
Yeah. I have to disagree with this one, at least in part. During pure development phases of a project, sure. Incremental improvement. But once you hit alpha and trough to GM? No way. In my experience, every change you make is just as likely to introduce a problem (or change an expected behavior) as it is to correct one. When things are running fast and loose, that's fine. When you want control quality as you move toward release, this approach couldn't be more dangerous.
When I first read this post I ran away scared shouting for help. I'm a software tester ;) But I agree, as long as this happens in a development phase there's no problem. We're likely to bump into problems during regression. Some developers informally let me know if they made small changes or updates so I can retest during "dead" moments ... that's the way of working I prefer. No need to scare project managers, team leads etc ... Otherwise, great post!