That's an excellent metaphor (or is it a simile?) and it fits in with my big company experience pretty well.

It's a lot less relevant to the small to mid size market where I tend to work now, and where things happen more quickly and spontaneously.

I hope this doesn't sound too cynical- I don't mean it that way- but after many years in this business, I've concluded there are only two "right" answers to the queston "Is this a good way to develop this project?"

The first one is "It is if my technical and business instncts and training tell me it is." Of course that's an ellusive criteria and it changes day by day as new gadgets and techniques emerge.

The second one, and it's a close second, is "It is if someone will pay me what I ask for while doing it that way."

I have to have both, but I alway consider them in that order.

The two harmonize more often than not, and that's what makes this profession such fun!

Regarding agile development, I'll have to check it out.
I was on teams who used PERT or variations of it quite successfully on some very large projects when PERT was the flavor of the day during the 60's and 70's.
There were 30 or more people on a team then, and projects ran for years.
Now Mark Z and a couple of his buddies write a billon dollar app in a few weeks in their spare time!




>>Have you ever been involved in a construction project? Everything is defined upfront and scheduled out in minute detail. Look at blueprints and you'll see where every lightswitch, wall socket, door jam will go. The exterior is specified and drawn out. Site plans show how to grade the land, how far back on the lot the building will sit. It's all waterfall management.

You just can't do software that way. How many times does software come in over budget and late. Using Agile techniques you can eliminate many of these issues. Don't plan things in detail. Do you plant a tree and plan where every leaf will go? Sometimes you need to prune trees. You do this with code, it's called refactoring. You need good soil for your plants to grow well. That's good OOP usage.

Code grows and changes in unpredictable ways, as do plants. Plants need to be cared for and nurtured. So does your code.

There are other comparisons, but I don't want to give away the entire presentation.

>It's hard for me to dispute that without even knowing what the phrase means. Google offers no help. Can you offer a definition of software gardening?