Leave the Campground Cleaner

Here's a little known fact about your Agile Zone Leader - I'm an Eagle Scout. I spent many happy years in the Boy Scouts, and this meant many happy weekends camping and hiking. Many of you may have heard of one of our camping principles: "Always leave the campground cleaner than you found it." Now I'm not the first to bring this up in an agile software development context (see Uncle Bob), but I hope I'm not the last.

It was very important to us as Scouts to be a good steward of the Earth. Until we colonize other planets we'll only have one to live on, and it's incredibly important that we take care of it. We knew that the next set of campers would only be able to enjoy our campground insomuch as we left it in good shape for them. Who wants to show up at a campground and spend his first hour picking up trash? We certainly didn't, and we knew the next group wouldn't either. So not only did we take care to keep our mess under control while we were there, we also spent a few minutes doing what we called "policing" the campground before we left. We'd line up across one end of the campsite and then march to the other end, picking up anything in our paths that didn't belong. Inevitably most of what we found was there when we got there, so we regularly left our sites cleaner than we found them.

This is the EASY way to do it. I tell my children all of the time that if they clean up their toys as they go, they'll never have to clean their rooms. This doesn't stop them from repeatedly ignoring my advice and piling up a huge mess in their rooms. They then have to spend a protracted amount of time putting everything away, resulting in a great deal of weeping and gnashing of teeth.

As it turns out, we didn't learn very much growing up from children to become software developers. All too often this is what happens in our code. We get so anxious to move on to the next feature, we forget to clean up the trash that we've left lying around:

• duplicated code
• poorly named classes, methods, and variables
• huge functions
• magic numbers
• inappropriate combinations of differing levels of abstraction
• tight coupling
• low cohesion
• high cyclomatic complexity (otherwise known as "spaghetti code")
• and the list goes on...

If you clean these smells up as you go, they'll never pile up very high. Your codebase will continue to be a joy with which to work. Let these things pile up and soon they'll turn into defects. Not only that, you'll have an increasingly hard time adding new features to the code as you have to spend more and more time wading through the garbage.

Even the best intentioned teams will occasionally leave trash lying around. So it's an incredibly agile thing to practice a little collective code ownership and clean these things up when you see them, even if they aren't your trash. You'll keep your team and your code happier, and folks will inevitably return the favor.

This practice isn't limited to production code. Don't forget about your tests. Unfortunately, in pressure-filled situations with immovable deadlines, automated tests are always the first thing to go out the window. I'll start out by saying that these are the last things that ought to go out the window. Quality and speed are NOT orthogonal concerns. There is a spectrum of design for any given feature. On one end you have the "perfect abstraction," complete with all of the elegance entailed by that perfection. On the other end you have the solution that gets the job done, but doesn't win any points for style. The point is that it is possible to implement either of these solutions without writing crappy code. Not only that, it's possible to implement either of these solutions with 100% test coverage. And you're never going to be able to refactor from solution A to solution B if you don't have that coverage.

With that said, you're going to skip tests from time to time, and so will your teammates. Many times you won't be on a so-called "greenfield" project and you'll inherit a poorly covered codebase. Here's a suggestion: write 1 test per day for an uncovered area of your code. Working like that you'll add somewhere between 200 and 250 tests to your codebase in the course of a year (correcting for weekends, vacations, etc.). Not only that, you'll leave your test suite a little bit larger every day. Now that's a happy campground.