The code garden (an analogy that sucks less)
(April 26th, 2007)
One of the most pernicious notions in software is the factory analogy. The idea that through some highly-repeatable process we churn out fresh software that gets delivered to people who use it unchanged for a long time. The reason this idea is so dangerous is that it is easy for non-technical managers to understand and it puts software development into a context they are familiar with (at least in theory). Of course, anyone who has written software knows this analogy is also utterly unrelated to software development. Hence, many developers encourage the bridge-building analogy. Managers understand this analogy as well, and it has the benefit of acknowledging that each thing built is a unique creation (at least largely so). Unfortunately, I think the few similarities between software development and bridge building are outweighed by the vast and irreconcilable differences between them. My biggest problem with these analogies is that they run contrary to the most important fact of software development: that software is never finished1.
It is undeniable that the initial delivery of a piece of code represents a tiny fraction of the expenditure on it. The vast majority of the costs will come in future revisions and maintenance. It will be tweaked, molded, adjusted and hacked until it has become too obsolete to be used. Given this fact, an analogy that describes only the relatively small initial creation phase can lead to some very bad habits. Sometimes maintenance and upgrades are ignored from planning altogether, other times they are under-acknowledged or allotted a fixed percentage of development resources. When these practices lead to failure, the tendency is to blame the developers and assume that they must have written bad code. This makes sense when you believe that software is like a bridge that gets built and then stands the test of time with virtually no maintenance. This notion explains why its so hard to explain to some managers that the requirements kept changing, or the basic concept got tweaked along the way. To them that sounds like bad up-front design. It argues for better planning so you can get it right the next time. Even though half a century of experience tells us that will never happen. These construction analogies also explain why the most common question managers ask is, “when will it be done” even though the actual right answer is, “as soon as no one needs it any more.”
This has led me to try to think up a better software analogy so that managers and software professionals will think about software in a more realistic way. Basically, an analogy that sucks less. So far the best I can come up with is the code-garden analogy. Basically, code is like a garden. We lay it out, plant it and then tend and maintain it for as long as it continues to warrant the attention. I like the analogy for several reasons:
- It recognizes the value of balancing planning, initial execution and ongoing changes and maintenance.
- It’s a resource constrained model. If you want a big garden you can either pay a lot for maintenance, spend more money on planning (soil preparation, irrigation, etc) or choose less complexity (big green grassy areas instead of intricate plantings).
- It implies that when the garden reaches a certain size and complexity there is no way to add to it, only to replace things that are no longer in use.
- It imparts the reality that you can trade off quality for quantity, but only up to a point. You can have a tiny Japanese style garden where every rock and twig is given consideration, or you can allow a small amount of weeds.
- It supports the notion that when things become to poorly maintained they may be easier to replace than to salvage (90% weeds, 10% flowers).
- It encourages people to think about how the software is being used. Areas with heavy traffic need more maintenance. Areas with less use need less, but when things stop getting maintained they will stop getting traffic.
As humans, we think and speak using analogies and invariably they affect how we act. While some people may feeel that your basic software process analogy doesn’t matter at all, I find that giving people a better analogy is one of the best ways to quickly change how they think about things. Of course, this analogy has holes as all of them do, but I think it’s a useful way to talk about and think about software development, and its certainly a lot closer to what we actually do than the factory model is.
(1) In talking about software development, I’m excluding game development and (too a lesser degree) embedded software development. These types of development have critical differences and need better analogies.
April 26th, 2007 at 2:29 am
That sounds like a decent analogy, but I also like the one presented by Martin Fowler in Rapid Development, where software development is like building a house. It covers all the areas you mention, and I think relates to more people.
April 26th, 2007 at 4:59 am
Actually, the bridge analogy is in face correct.
Without proper ongoing maintenance, the bridge will fall down. Many bridges built in the 1930’s and 1940’s required massive repair projects to correct the problems of deferred maintenance.
And as with a bridge, you need major redesign work when the assumptions of the original design become obsolete.
April 26th, 2007 at 9:23 am
[…] In this post Kevin Barnes make the analogy of software development being a “Code Garden”. Best analogy or not for describing the software process to the unknowing, I enjoyed reading Kevin’s justification of the analogy. […]
April 26th, 2007 at 9:36 am
Kevin,
I think this analogy is elegant. I was discussing the analogy problem with my CEO recently, and he dismissed construction and manufacturing as candidates. The best I could do at the time was compare us to an ad agency where a creative team builds something unique for the customer.
I’ll be using your code garden analogy in our next chat.
Cheers,
++Alan
April 26th, 2007 at 9:38 am
I think Steve McConnell suggested this in Code Complete: programming as farming. Thomas Guest backs me up in a recent post that sort of makes the same point as one of yours: http://blog.wordaligned.org/articles/2007/03/14/why-software-development-isnt-like-construction
April 26th, 2007 at 10:27 am
I’m not sure the gardening analogy is really all that apt. The most important things about gardening, in my limited experience, are that you have to do the same thing many, many, many times; most of that work can be done almost equally well by an uneducated six-year-old and by a master of the craft who has spent their life on it; it hasn’t changed much in thousands of years; even the best research teams in the world can only make much of a difference in it after a decade or more of work; and most of what happens is out of your control, because it depends on the weather and pests and the like.
By contrast, when you’re programming, if you have to do the same thing more than twice, you’re probably doing the wrong thing and should program the computer to do it instead; every year I learn to do things I couldn’t imagine how to do the year before; the nature of the process has changed dramatically even in the last ten years, even though the deepest insights of forty years ago still hold; often even a few months of research with the right idea can make a big difference, although it takes 10-40 years for the rest of the world to start using the research idea; and none of what happens is out of your control.
April 26th, 2007 at 2:10 pm
Hi Kevin. Thanks for the post. To back up what Kragen Sitaker says, Steve McConnell does devote a whole chapter of Code Complete to discussing various analogies for software development (note: software development and not just programming). He rejects the gardening metaphor primarily because gardeners can’t control factors such as the weather, which have a huge impact on gardening, and then goes on to select the metaphor of “construction” as the one he prefers. I disagree [1], and argue that the construction metaphor can be downright dangerous.
I take your point: that software is never really finished. We should tend it, keep it simple, and make sure that the code and the executable are never separated. Incidentally, I notice your blog covers all bases: “Code Craft: The Art, Science and Craft of writing quality Software”.
April 26th, 2007 at 6:17 pm
Nice read but I think I have the optimal analogy for software design. I like to think of software development as something that is BOTH unique and similar - unique in terms of its result, but similar in terms of its comparison to other results, meaning other applications.
Without getting too philosophical in the aforementioned introduction, the analogy for me of software development can best be compared to a painter who paints a picture of the sky - but only the sky because that represents the constant in software design which is that of its fundamental basis for which it is constructed. It entails the creation of an electronic means by which to manage data. However, like a painting of the sky which primarily consists of painting clouds, NO cloud combination is the same. The color, texture, size, and shape of the clouds will be different. Their relationship to other clouds within the picture will also be unique. However, the picture will primarily consist of only elements which can be found in relation to the sky - clouds. The sky may be painted as a day or an evening image which will also reflect additional unique but similar characteristics. A day sky might contain a blue background and an evening sky may represent a darker hue of blue, gradients of gray or plain black, and, instead of clouds may present the viewer with different representations of stars or may strongly convey a more constellation-like image.
In addition, no TWO painters will paint the same picture of the same sky with the same clouds in the same way….each painter will see the picture differently in his mind’s eye which will translate into a different context of the painting both in space and in time. This is much like software development where there are again, unique but similar elements to its construction.
The sky is always going to be the sky….you must look up each time you want to capture its essence. Like software design, you must deploy the same kinds of elements to construct a data mosaic of your application.
And, occasionally there will be elements so unique to your application that it sets it apart from all others yet it will still contain similarities….think of the occasional painting which, in addition to presenting clouds and a blue integrated sky, may also show unique additional elements to the painting such as an airplane, birds or a mountain backdrop.
Software development may contain fundamental elements of its construction such as combo boxes, radio buttons and list boxes, but it may also contain coding algorithms so unique to the application that it sets it apart from all other applications.
This analogy I believe best describes the software development paradigm.
April 26th, 2007 at 8:59 pm
You’re right, your analogy sucks less. It’s an improvement, but I don’t think it’s near close enough to be useful if only because maintenance is still under-valued in a gardening analogy. In a garden (as with all construction analogies) all maintenance can be performed by drudges after initial architecture and design. Software development doesn’t work like that–you need top-notch design in maintenance and refactoring as much as you need it in the initial stages.
Personally, I prefer to compare software development to other professions that have on-going maintenance and/or iterative cycles. So far, that means research scientists and lawyers. Both have to react to changes outside of their control and have to revise past work to fit current realities (from both internal and external changes).
April 26th, 2007 at 11:44 pm
Interesting analogy. Not least because it allows for the fact that less skilled “gardeners” can be given a framework for modifying the garden e.g. “This area has lots of sun and poor watering but you can plant anything you like that will survive those conditions”. Getting programmers to think of some of their users not just as passive consumers of the “garden” but active in its development would be very useful.
JT
April 27th, 2007 at 8:32 am
See http://alistair.cockburn.us/index.php/Whatengineeringhasincommonwithmanufacturingandwhyitmatters
It explains that the end of the production line is essentially a decision, not a product. A product has lots of decisions (tickets, features etc.). Each of these has to be supported etc, just in the same way a manufacturing product does. If your design/production line is useless, you’ll spend a whole heap of money making [code] decisions, and they’ll cost you more later, because customers will return them.
But it makes it quite abstract. Analogies that give a better face value inspection as above are useful as well.
April 27th, 2007 at 8:33 am
http://alistair.cockburn.us/index.php/What_engineering_has_in_common_with_manufacturing_and_why_it_matters
April 27th, 2007 at 8:48 am
[…] Kevin Barnes recently shows how a code garden makes more sense than the usual factory comparison. There have been more in the past: […]
April 27th, 2007 at 9:04 am
[…] Used to be, software development was compared to bridge building. But no one likes that anymore, and there’s an ongoing search for a better analogy. Software development is a game. It’s gardening. Rock climbing. Gardening. Painting. Gardening. […]
April 27th, 2007 at 10:01 pm
I think this analogy is much improved over the construction-based analogies that are currently so common. And it turns out, much the same analogy has been employed already in The Pragmatic Programmer — chapter 6, page 184, “Refactoring” — the section I was reading just last night.
April 29th, 2007 at 6:23 am
[…] [CODE] The code garden (an analogy that sucks less) (codecraft.info, 29 saves) […]
May 1st, 2007 at 2:44 am
Love the analogy…
May 1st, 2007 at 3:19 am
Haven’t I seen this analogy here before - just recently? http://lostgarden.com/2007/02/rockets-cars-and-gardens-visualizing.html
May 1st, 2007 at 3:46 am
I like the analogy, but I don’t know if creating analogies for software development is a good thing.
Not only does it lead to the problems of arguing by analogy. For example, it can lead to nonsensical arguments such as if software development is gardening, what do the apples and oranges I could grow in a real garden represent in software development. What’s the difference between different types of fruit.
Also I haven’t ever heard another discipline comparing themselves to software development in the same way we do in SD. My gardener, for instance, has never said to me “Gardening is like software development” when trying to explain why he’s pulling up the weeds in the garden.
Why don’t we say “Software development is software development. It has similarities with many other parts of life, but it can’t be fully reduced to another paradigm.” And then add with biting wit, “Would you ask your accountants to explain what they do in terms of pearl fishing?”
May 1st, 2007 at 5:55 am
“”"Also I haven’t ever heard another discipline comparing themselves to software development in the same way we do in SD. My gardener, for instance, has never said to me “Gardening is like software development” when trying to explain why he’s pulling up the weeds in the garden.”"”
Maybe I ain’t your gardener, LOL…
http://samfeltus.com/as3/primavera2.html
May 1st, 2007 at 8:51 pm
No analogy is perfect, but this has a lot going for it, particularly your reasons 2 and 3. I’ve been blogging some about knowledge gardens, and would suggest you could strengthen your analogy by looking at what ecology and particularly ecosystems have to do with knowledge work (http://en.wikipedia.org/wiki/Information_ecology has some starting points).
May 3rd, 2007 at 9:26 pm
My company has recently been bought by new owners. The new CEO really likes the factory production line analogy with a warehouse of “parts” that can easily be assembled on the production line and shipped out. I have tried to point out the flaws in that analogy, but since he doesn’t know much about software and is just someone who goes around buying companies (in various industries), he doesn’t actually know much about software and doesn’t get it.
I like the garden analogy. But I was thinking the other morning about analogies in general. Just because an analogy appears to hold for a particular scenario, that in itself is no reason to use it. People get caught up in analogies sometimes and keep following them without realising that they are starting to break down.
I do it myself - I really enjoy coming up with analogies and make them up all the time. Then I try to infer things from them and suddenly realise I’m being ridiculous. For example, had I come up with a trivial analogy between a bicycle and a honey bee (I can’t think of one now, but I’m sure I could if I tried for a while), my next line of thought might well start “given that a bicycle is like a honey bee, it follows that…” before I mentally slap myself and tell myself to get a grip. To people who don’t really understand logic, that might well seem logical because they just accept the initial assumption based on the analogy that seemed to hold for one particular case. I know that’s an extreme example and its ridiculous nature is quite obvious, but that helps to make the point.
May 3rd, 2007 at 11:36 pm
[…] Software is new. There are many discussions around what analogies are appropriate (see the recent debate at Code Craft for a start), but ultimately it’s new and there are no complete analogies - it’s not engineering, it’s not science, building software is not like planting a garden or building a house. It’s new. […]
May 5th, 2007 at 7:39 pm
There has been much debate of a simple analogy; that building software is like building a house and that software development is like construction. Having read and considered the all arguments surrounding the software construction analogy and given that both camps have appeared to rest their cases, it was appear to be an opportune time to reach some kind of determination on the matter.
May 30th, 2007 at 3:32 pm
[…] It started with this Code Craft blog post on the Code Garden - an analogy that sucked less. It got me thinking and ranting about metaphors in software and metaphors of software. Designing your technical architecture with software, the XP “Metaphor” practice, metaphors for HCI, metaphors like those used in the Head First series and Ajax Patterns to explain concepts, metaphors to explain what software is to managers. Where do they make sense and where is it plain wrong to try and explain software with a metaphor. […]
October 17th, 2007 at 1:38 am
[…] “The code garden (an analogy that sucks less)” Comment via Email Previous: Podcast: Software As She’s Developed Marco’s Webdev Notepad […]
January 30th, 2008 at 7:58 pm
[…] Even out of an agile perspective, this is a good practice to keep code simple, maintainable, easy to make evolve and avoid what I call the Critical Code Mass. This post of Kevin Barnes on The Code Garden is worth to be read and is also talking about code evolution capability. […]
February 18th, 2008 at 3:37 am
[…] Tagged Gold card Kevin Barnes suggests that software engineering is a bit like gardening - software is never finished - you need to spend some time planning, some time adding new features and some time tending to what you have. Otherwise your code will become steadily more and more unmanageable. […]