In one of the best programming books I've ever read, The Pragmatic Programmer, it is written: Programming is Gardening, not Engineering.
What are your thoughts on the "Gardening" metaphor?
Do you agree with this metaphor?
If yes, why do you think, it's not used more often? (I've never heard it used anywhere else, except the book)
I think it's has some truth to it. Programming seems to be a continual search and destroy operation on bugs (weeds). On the other hand, in gardening this is from the garden changing, int programming it's from a continually changing set of uses for the program.
I've thought it odd that one of the most "broken" classes of things that man has created is the one systems we have created that can't actually break.
I think the reason it is never used in common practice is that if this metaphor was presented to the client, you would never get the work - this metaphor = more cost upfront.
You are essentially already telling the client that no matter what, we will definitely have to rewrite code, and bugs will definitely be there post delivery, and all kinds of bad things will happen.
I think it is a better metaphor than the engineering or construction metaphors. The gardening aspect works for me because I like to think of the code base that I am working in as a living thing that is constantly changing and evolving much like a garden.
I've often wondered if the fact that the building/constructing metaphor seems to be used all the time has something to do with the inspiration that was taken from "The Timeless Way of Building" which apparently inspired the software design pattern movement way back when.
Good metaphor - requires constant feeding and grooming, and has a life of its own.
I much prefer the swamp metaphor.
Your team has to find a certain place in the swamp, but it's not clear where that place is, or whether its location will change while you're navigating towards it. Once you've found all the nasty surprises between you and that place, and your team has laid a rickety path between the two locations, you then have to lay a 3-lane highway for the end-users.
And you have to do all this at night. Wet. Wearing goggles :-)
In general the most abundant source of metaphors do seem to come from building as per the Code Complete book.
However, I think to each situation each can find their best set of metaphors. Sure, it depends on who you are trying to express what to.
Are bugs weeds or rust?
I think the gardening metaphor works pretty well in the context they were using, i.e., contrasting it with the idea that programming is merely following the direction of the architect, plugging in the components that the architect has chosen. I don't know that it is a particularly good metaphor to describe programming in general. Like any metaphor, you can only carry it so far.
I think the gardening metaphor is a fairly realistic view. I don't think that's how it should be however. I take a scientific and engineering approach to all my work, and I do think that's important. We shouldn't become too focused on the mess of brambles else that's what we'll inevitably end up with. You have to be realistic of course, and I doubt any strain of engineering is as pure as it perhaps "should" be, and maybe ours is worse than most (it's an immature industry after all).
I actually don't agree with the implied view that engineering is a fixed, inflexible process unable to cope with imperfect situations.
So I would say it's useful in passing - aim for engineering, but bare the garden in mind.
I never have cared for the gardening analogy, personally. While I see the intent, I have always thought that it was a backhanded categorization. Gardening is a hobby for most, and a profession for few. People that fall into the hobbyist aspect don't care what it is called, but professionals are a different beast.
I prefer to look at it more as parenting. You have to raise it, spend many sleepless nights worrying about it, have to correct its behavior when it is wrong, and constantly teach it to do new things - all eventually to send it out to the world on its own and hope that it will succeed. It is the analogy that best defines "development". I think that is why I have always disliked the term "programming" in favor of "development". To me, programming has a hobbyist ring to it, while development - or more appropriately, software development, conveys the responsibility and lifecycle of what we do.
On a related note, development in general is really a mix of art and science. You have to remain confined by certain constraints to meet your goals, but the black box that the solution lives in can be derived in countless ways. You can give 20 developers a project and get 20 different solutions that (theoretically) live within the same boundaries of operation and functionality.
the gardening analogy only works if you defined 'gardening' in the continual-landscaping sense that the author describes, which hardly describes the familiar kind of growing-some-lettuce-in-the-back-yard gardening. The 'adaption' part of the metaphor sort of works, but makes a huge assumption about the audience's familiarity with a particular kind of long-term yard sculpting - the concept of a walk-through terraced backyard 'garden' is largely unfamiliar to most urban and suburban dwellers, for the simple reason that such things are expensive and rather hoi polloi to begin with. I've only seen one house that had one, other than the Biltmore House.
Furthermore, though our family had a garden when i was growing up, i was never very interested in it in the first place, and in the second place our garden was for edible things, not color-matched trees and flowers. And in the third place, everything died in the winter. I don't know about your code, but I don't want people to think that my code dies with the first frost and doesn't return until spring!
So in general i think it is a silly metaphor that breaks down immediately:
it is also silly for the simple reason no metaphor is required: writing software is science, engineering, and art/craft, all at the same time. Only the most green/academic of engineers believes that top-down design and implementation is all there is to 'engineering', that everything follows the plan like clockwork. To paraphrase military doctrine:
no plan of battle survives the first encounter intact. This does not remove the benefits of making the plan in the first place.
I prefer to say that programming is alchemy not chemistry.
Prospects for an Engineering Discipline of Software by Mary Shaw.
Never thought of programming as gardening but it would fit since my number one favorite Chinese proverb is "Nothing is as important as gardening and even that isn't really that important."
There is a difference between Programming and Software Engineering. Absolutely there is.
The difference is how software is built. A number of people who call themselves "Programmers" work in a shop that institutes Software Engineering metholodogies and principals, and should be called a Software Engineer.
Conversely, a number of people with the title "Software Engineer" may actually be in a shop where they are really just Programmers.
Software Engineering versus Programming. Good topic.
Probably gardening is much more like engineering than software engineering is ;-) I think plants and gardens and even wheather (on the scale of a year or two) are much more predictable upfront than any software engineering project is.
On the other hand, by definition (merriam webster, clause 2b) software engineering is engineering.