Agile Zone is brought to you in partnership with:

Matt is the Group Leader of Research Application Development in the Research Informatics Division of Information Sciences at St. Jude Children's Research Hospital in Memphis, Tennessee. Matt has been developing and supporting enterprise Java applications in support of life sciences research for St. Jude since 2001. Matt is a committer to multiple open source projects and is the founding member of the Memphis/Mid-South Java User Group. Matt is also a regular speaker on the No Fluff Just Stuff symposium series tour (as well as other major conferences), and his articles have appeared in GroovyMag and NFJS the Magazine. His current areas of interest include lean/agile software development, modularity and OSGi, mobile application development (iPhone/iPad/Android), web development (HTML5, etc.), and Groovy/Grails. Matt has posted 44 posts at DZone. You can read more from them at their website. View Full User Profile

Leave the Campground Cleaner

11.17.2010
| 12260 views |
  • submit to reddit
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.
Published at DZone with permission of its author, Matt Stine.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Xebia Labs replied on Mon, 2010/11/29 - 12:18pm

Matt, great article. It’s so important to fix the problems with code before they pile up to prevent any serious consequences. But luckily, there is deployment automation software that can essentially prevent the trash from ever needing to be picked up. Because this software automates deployments and tests, it eliminates the human element so that duplicated code and poorly named classes, to name a few, no longer are a problem. And not only does this save time with the deployment itself, but also makes sure that no one has to go back and “clean up the campsite.” Do you agree that deployment automation is an effective method to prevent trash collecting in code?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.