Engineering in Focus

When I get a glimpse into what other people do all day I sometimes see similarities and sometimes differences. One of the activities that has always seemed most similar to developing software, and especially to agile software development, is gardening.

I’ve long been a member of, and for the last few years have run, the volunteer group which maintains the little park on my block. One of the many benefits is that we get to work with and learn from professional gardeners: a couple of different gardeners who have been permanently assigned to our park over the years, and half a dozen who have taken turns supervising the volunteer group on our Saturday work days. Every one has plenty of detailed technical knowledge (don’t get them started on plant names), and also a fund of practical wisdom.

Others have compared software development to gardening, often pointing back to Fred Brooks’ “The Mythical Man-Month”. (“[Software] is grown, not built.”) I’m not so interested here in exactly how accurate the metaphor is — if it were perfectly accurate it wouldn’t be a metaphor, just a description — but in what of that practical gardening wisdom translates to software development.

The comment that first made me start thinking about this came from one of our supervising gardeners, a young guy who liked his time off as much as he liked his time on the job. Some of us volunteers were deadheading (removing dead blooms from) a row of lavender bushes. “Don’t stay on one plant until you’ve gotten off every last one,” he said. “Work on each plant for a little while. That way it’ll never look like you worked on some plants and not on others, and when the boss calls quitting time, you’ll always have something to show for your time.” I’d never thought of gardening that way, but it is exactly the agile principle of delivering frequently. (“Don’t stay on one plant until you’re done” might seem like the exact opposite of the sashimi principle, but deciding to trim a plant less is choosing a smaller task to do, not doing a task incompletely.)

Once you start listening for agile principles in the wild, or in the park, you hear them everywhere, so let’s just extend that metaphor:

At a longer timescale, both professional and volunteer gardeners iterate — that is, we return to the park daily or weekly or monthly, after which the public sees the result of our work right away. Because we iterate, we don’t have to worry too much about what exactly gets done on any given work day: if we miss some weeds one month, we’ll get them the next.

Just like a software project, a park is a complex system made up of parts which in some cases depend critically on one another: plantings, hardscape, irrigation, the electrical system, play equipment, buildings. And just like software, parks degrade through usage, changing needs, and deferred maintenance. That irrigation system is a constant example: if the irrigation goes out, plants die, leading to more work to replace them than it would have taken to fix the irrigation. Fences protect plants from roving dogs; without them, again, plants would have to be replaced more often. And the best investment is to plant plants that can handle dry conditions and wear and tear when they have to. In each case, the path to sustainable maintenance is to eliminate waste and to invest in quality before an issue becomes a problem.

Our regular gardener, who takes care of the park during the week, knows what kinds of colleagues he wants. One guy is great because he’s able and willing to do anything: caring for plants, picking up trash, hauling stuff, fixing the irrigation. Whatever job needs to be done, he can help. Another guy only wants to bother himself with the plants, so when he’s on duty some jobs go undone. Just like a software team, the gardening team works better when everyone works full-stack. And to push everyone in that direction, our park district manager moves people from job to job regularly so they regularly acquire new skills.

(Our park system hasn’t made the leap to devops, though. Specialties like tree trimming, carpentry, painting and electrical work are all specialist fiefdoms, and a gardener who does any of that work risks the wrath of the organization. Irrigation seems to be a gray area.)

The biggest factor in a healthy park is the involvement of its neighbors. This is true at many levels: not only does the monthly contribution of our volunteer group make a difference, but so does every neighbor who calls or tweets 311 or Parkscans to report an overflowing trash can, a tag or a broken swing. Some sources of park funding are only available when neighborhood groups work to request them. And we’ve found that the effort we put in comes back severalfold because the park department knows we care about our park and we’re keeping an eye on it. This is exactly the agile principle of involving the customer to better align work with customer needs and wants.

It’s fun to look for these parallels, but it also reassures me that there are real principles behind the way we work, principles bigger than just software. I’d be interested to hear of another field (so to speak) that is outwardly so far from software but that shares so many of these principles.