Stoop and Scoop

We have a dog... a big dog.  Hannah is a very active Golden Retriever who is programmed to be one of two states - on a walk or wanting to be on a walk.  She accepts swimming as an acceptable substitute for walking, but that's another story.  So, each and every day in practically any weather we take her out for her exercise.

Being a dog, Hannah isn't particularly fussy about where she, um, takes a bio-break.  Now, we could simply look the other way and pretend that we didn't see what just occurred but, again, she's a big dog.  Since we follow a couple of well-worn routes around our neighbourhood and in the park behind, the accumulation of doggy doo would be quite significant very quickly.  Add to that all the other dogs, large and small, in our area and you would have piles upon piles of... I think you get the picture.

So, being the good citizens that we are we stoop and scoop, cleaning up the mess right there on the spot.  We diligently take it back home in a plastic bag and toss it in the garbage.  Most of our neighbours do the same, and the area is the better for it.  There have even been times when we've cleaned up the mess from other dogs whose owner were not quite so diligent, all for the greater good of our neighbourhood.

Imagine for a moment that the code in which you work is your neighbourhood.  When you are adding new code or making changes, do you want to be stepping in all the crap that other dog... er, code owners have left?  Do you think they want to step in the crap you 'neglected' to see because you looked the other way when your dog decided to stop?

Of course not.

When you're writing code, do the equivalent of stoop and scoop.  Ask yourself if the code you're writing, be it production code or tests, is adding crap to the neighbourhood.  If it is, clean it up!  I'm OK with the idea of getting the code to work and then refactoring to improve the design, but I can say from experience as both a programmer and dog owner that the smaller the pile of crap you have to clean up, the easier it is on the senses.

For the 'how' part of cleaning up the code, Joshua Kerievsky's Refactoring to Patterns is an excellent place to start.  His company, Industrial Logic, also published a cheat sheet for Code Smells to Refactorings that is a very helpful starting point for identifying what's smelly about the code and patterns for how to remove the smell.  These are small, stoop and scoop steps that will help you to prevent the construction of a large pile of crap that does nothing but smell!

So remember, other people have to live in the same neighbourhood as you.  Be a good neighbour - stoop and scoop your code!

(Please note - any "this is a crappy blog post" comments will be summarily marked as spam! :)

Comments

Matt Badgley said…
One of my favorite analogies and very nicely told. As someone from Dev leadership background, I cannot say enou good things about what Industrial Logic is doing to help improve the craftsmanship of engineers. Great post.
Simon said…
Very true Dave.

I would like to add another thing here you didn't mention that'll add to the analogy.

I bet you scoop more if you walk with someone else.

- Pair Programming & Code Reviews
Dave Rooney said…
LOL!! I love it, because that's so true!

Somewhere in the deep, dark past I wrote about how peer pressure was one of the dirty little secrets of pair programming. Having someone work beside you definitely does keep you focused on work rather than taking the occasional break to surf the web, etc.

It's not something that a lot of people seem to want to talk about, though.
Todd Charron said…
(Please note - any "this is a crappy blog post" comments will be summarily marked as spam! :)

Awwww, crap! :)