Software Engineer is what reads well on the resume but Software Gardener reads well to the experienced. The analogy that building software is more like gardening vs engineering has been around for a while. You can find other articles with very good descriptions of the analogy. In short: “In engineering, the final product is defined up front and is created to the t. In software the final product is rarely known up front, and even rarer does it end up like the initial plans call for. It is simply not possible or desirable in most projects. Thus developing software is more like gardening: You have a tentative plan, you plant the seeds, but it’s an ongoing process, in which you can never guarantee exactly the end product. We can tend to the project and guide it to have the desired results at any given time while adapting to the real world environment.” This is also the basis for agile methodologies which is why I believe I am both an Agile Professional and a Software Gardener. What hasn’t been explored is how development best practices extend this analogy.

Skip article version and jump to a mind map of the same content

Pair Gardening

Planting new features is done in pairs. Pair Programming is an Extreme Programming technique in which two developers work side by side at the same computer to accomplish a task. Who gardens alone? Someone digs the hole while the other hauls the wheel barrel. Good luck planting that tree alone. Also, let’s be honest, misery loves company. Melting in the heat, doing repetitive work, it’s always done better, faster and more fun when done with a friend.

Driving around my neighborhood I see husband and wife, grandma and kids, or sometimes hired hands, working in the yard together. We still work on software individually, watering alone, pruning the excess, spotting weeds to demolish and features to improve later. When the real work starts, when the real effort is applied, we work together. We software garden in pairs.

Test Driven Planting

Test Driven Development is among the top practices experts and the experienced advocate and one of the last techniques most developers adopt. Think back to your first gardening projects. You go to the store, you buy some plants, you roughly read the 2 inch card describing its api and you stick in the ground. Some of us go right in the dirt, some are smart enough to know some potting type soil should be used, while the clever ones mix the two. Ultimately though we don’t know what we want before we start, we just start and figure it out as we go.

The really experienced gardeners draws out the plan, defines the size of flowers and plants for the area and determines the amount of sun required to accomplish the goal upfront. Then they work toward that goal. Experienced developers determine how to achieve customer value, the best way to interact with an api, setup the tests first and then work to accomplish that goal. This isn’t to say we know exactly what flower will fill each space, but we know how big and how much sun it needs so once we start shopping, once we start the hard work, we have a criteria to meet.  There is a pass/fail achievement and we know when we are done.

Refactoring our Planted Debt

Refactoring is making changes that do not affect behavior of a program. This includes things like cleaning up the code, documentation, moving objects around to be more usable, adding tests etc. This is one of the easiest analogies to gardening.

Pulling weeds is to cleaning up the code. If you don’t technical debt overcomes the garden.

Watering and raking leaves is to improving speed. You don’t have to do either but really should.

Moving plants to improve the feng shui is to improving the software design.

Fighting off squirrels and leprechauns is to fight off garbage collection locks and memory leaks. Damn leprechauns.

Pruning is to removing unused features. More than refactoring but it fits most here.

Mythical Man Month – Time is Needed

The Mythical Man Month made popular the analogy:  “It takes 9 months to make a baby, no matter what, you can’t use 9 people to make a baby in a month. Software is the same thing, you can’t always throw developers at a project to complete a project sooner, it takes time.” You know what else takes time? Gardens! You can’t make an apple in a month. It needs time, needs sun, needs refactoring, needs water, needs pruning, needs upgraded, needs rain, needs more memory, needs picking, needs time. You can’t do that list of things all in one day and call it a tree. You call that a waste of money.

You can buy a tree of a certain size. Sometimes that works great. Sometimes you plant a tree and it dies. Lowes will blame you for the death of the tree, just like your boss or system engineer who purchased an off the shelf solution will blame you for the inability to make it work. Sometimes you can’t buy the solution. You buy the seeds, you buy the shovels, and you buy the land but you have to put the hard work in and give it a little time for the best outcome.

Design

In software, design often doesn’t go as planned.  This is one of the primary reasons agile practices recommend emergent design. The same has been my experience with gardening.

Step 1: Decide how much money you want to spend on the new flower bed. Sprint Planning.

Step 2:  Preparation. Pull all the hose off the reel so far that it will never go back on like it had been sitting for the past 2 years. Download the Code.

Step 3: Make the shape of the flower bed you want around your tree. Task Breakdown.

Step 4: Spend way more money than desired for end result (really, for flowers?). Sprint Zero.

Step 5: Have nothing go as planned but come out with the best product that the team could accomplish at the time.

Step 6: Profit.

Peer Review

Let’s be honest, the garden is not for us, it’s for everyone else to see how awesome you are. That’s what peer reviews are for. You will get the grandmas that notice your semicolon could have faced the street and that would have worked so much better. Or the color of your mulch should have been just slightly more dirt colored. But sometimes you get that relative who suggests a better way of planting or a better frequency of watering etc which you can respond with “Hey… Thanks.”

Continuous Integration

You may grow a flower in a pot and then when ready you integrate it into your garden. You probably never planted tree seeds in your yard, you grow it separately, like at the store, and integrate it as soon as possible, but not too soon. Facebook is notorious for working in their production environment in real time, or near real time.  I argue just plant the flower directly into the flower bed and iterate on it instead of cultivating in a separate pot. This is one analogy in which we are better at in gardening and struggle to implement in development, yet experts and companies all agree it is the goal.

On Call Support

Something is on fire!!! It’s our job to put it out. Okay so probably not real fires in your garden, but I bet I know something you do have: Bugs… Bazinga! Sorry, I had to. Bugs are the easiest analogy to make given the name. As in gardens bugs are always going to exist in code. It’s our job to deal with them in the most appropriate ways. This doesn’t mean we stop everything every time we see a bug, it means if the bug is big and hairy enough you throw a shoe at it.

Have you ever had a sprinkler head water fountain in your front yard? Sometimes it’s so hot you water twice in the day. Sometimes the dog digs holes in your begonias. Sometimes the dog leaves presents in your begonias. These things happen, no one is at fault. Sure you could have put a shock collar on the dog, and trust us developers, we would love to shock collar our users, but that’s not realistic. The dogs are going to lift their legs, and it’s our job to clean up after them.

Development Duck

Some of us in the business know of a technique where you program a duck into the software. This theoretical duck is something for management to get upset about, something to absorb all the negative comments that a manager feels he/she is required to criticize in order to be a good manager. Then they won’t comment on all the real work that is great. Afterwards we pull the duck out to make it seem like they did something useful.

AKA the lawn gnome. Anyone try to help their spouse gardening? Anyone ever do anything right on the first try and not get yelled at? It’s impossible, I promise you. So go buy a lawn gnome. Plant a giant tree. Before your spouse makes you turn the tree 6 times, inevitably returning it back to it’s original angle, put the gnome right in front of it. You can spend time arguing about something trivial you don’t care about and leave the tree alone. Okay this one could have been a stretch, I tried.

Deliver Features

A major focus in agile is to deliver features useful to the user. You can only plant one flower at a time, no matter how hard you try. Rarely do you plant seeds and wait for everything to grow at once, you definitely shouldn’t these days. By the time they start growing you will realize you want different things. In agile you rarely work non feature tasks. You don’t build the framework everyday. One contrast to keep in mind is you rarely do plant one flower in a day though, you usually do it in batches. Just like sprints or other iteration terms. You bite off a handful of features and work to complete them at the end of the iteration.

At Dusk

Without arguing the engineering points I have extended the fact that we as programmers/developers/coders/software guys & gals are definitely Software Gardeners. Any analogy has its flaws but I think this one is holding up nicely. So much so I have switched over this blog to www.TheSoftwareGardener.com. Ultimately feel free to call yourself whatever you want but from now on I am holding onto the title: The Software Gardener.

Mind Map

Above is a lot of text representing my brainstorming mind map below. As I continue this career I plan on updating the analogies in the map below. Plus the mind map is easier to read then an article.
Interactive Mind Map of The Software Gardener