Interview: Pragmatic Programmers on Software Gardening


News: Interview: Pragmatic Programmers on Software Gardening

  1. Dave Thomas and Andy Hunt, the pragmatic programmers, have been interviewed about software development. They discuss topics such as how software development is more like gardening than architecture, firing tracer bullets, and the stratification of developer jobs.

    Excerpt on Gardening

    "Andy Hunt: Instead of that very neat and orderly procession, which doesn't happen even in the real world with buildings, software is much more like gardening. You do plan. You plan that you're going to make a plot this big. You're going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You've got a great plan, a whole design.

    But when you plant the bulbs and the seeds, what happens? The garden doesn't quite come up the way you drew the picture. This plant gets a lot bigger than you thought it would. You've got to prune it. You've got to split it. You've got to move it around the garden. This big plant in the back died. You've got to dig it up and throw it into the compost pile. These colors ended up not looking like they did on the package. They don't look good next to each other. You've got to transplant this one over to the other side of the garden.

    Dave Thomas: Also, with a garden, there's a constant assumption of maintenance. Everybody says, I want a low-maintenance garden, but the reality is a garden is something that you're always interacting with to improve or even just keep the same. Although I know there's building maintenance, you typically don't change the shape of a building. It just sits there. We want people to view software as being far more organic, far more malleable, and something that you have to be prepared to interact with to improve all the time."

    Read the interview with the pragmatic programmers: Gardening with Tracer Bullets

    Threaded Messages (12)

  2. OK, I need to vent about something. The principles they talk about have been known and expounded upon for at least ten years that I can remember. The authors are not saying anything new.

    None of this is the fault of either Thomas or Hunt. The simple fact is that the industry as a whole only pays lip service to best practices, and continues to shovel code regardless.

    A case in point is the "tracer bullet" technique they refer to. Back in the day we were talking about the same thing, except we called it "sliver" or "stovepipe" prototyping - a stake in the ground to find how the requirements squish and move in the areas of greatest risk.

    The gardening metaphor is another example. We have known for many, many years that the development process is really one of cultivation. In the mid-nineties I wrote an article for ROAD or JOOP about how the development process can be described as fractalform and I recall that Jim Rumbaugh and others were saying similar things at the same time.

    What I really want to read about now is not a rehash of best practices, but how the blazes we can get them to actually stick.
  3. Problem?[ Go to top ]

    What I really want to read about now is not a rehash of best practices, but how the blazes we can get them to actually stick.

    Ian - I'm wondering if you're thinking more about getting the influence to make the practices stick, or how to implement them.
  4. Problem?[ Go to top ]

    Ian - I'm wondering if you're thinking more about getting the

    > influence to make the practices stick, or how to implement them.

    Personally I'd settle for the influence to implement them, even just once! ;-)
  5. Repition reaps rewards[ Go to top ]

    That may be true, but the more times something gets said the more likely it is that oneday someone will listen. As practises and technologies change the metaphors and established wisdom have to be rephrased and often relearnt. There's no harm in that. We see this in business, religion, politics, art etc. The same ideas carry on but often the lessons have to be relearnt. And why? Well it's a whole bunch of new people how need to learn and most youngsters think a new idea is better than an old idea, isn't it.

    Management will learn to listen to developers, when the requirements team listen to them, and the requirements team will learn to listen when customers listen to them and customers will listen to the company when the company produces what it required. And the company will produce what the customer wants when the developers listen to the managers, and the managers listen to the requirements team and the requirements team listen to the customer and the customer ...

    We all look for someone to blame, but the reasons things are like they are is a general demanding culture that doesn't care about quality, workmanship, quality of life or in fact any human values - just output and consumption.

    So if we want things to improve we just gotta keep fighting our little battles and hell even if nothing else changes our self-respect will and that's gotta be worth something.

    Anyway it's always refreshing to here from these guys as they have a good way of capturing the essence of coding as a craft.
  6. Repition reaps rewards[ Go to top ]

    Alas, I know you are right. We need repetition to stand any chance in the larger struggle, and we do need authors like Hunt and Thomas to address the up-and-coming bunch.

    In the meantime, reality shall continue to exact its own revenge (fade to bitter, twisted cackling)...
  7. Just a note to say I think it's important that best practices such as those mentioned in the article, and those enumerated in The Pragmatic Programmer, although not new, are continually "rehashed".

    The problem I face more regularly than not is that developers simply are not aware of best practice. Perhaps it's just my bad luck, but the developers who know, adopt and extend best practice are in the minority. Of course they're a pleasure to work with.

    Perhaps the repetition and re-presentation of these ideas will help those of us who have to continually explain them to others and to have a greater selection of metaphors and anecdotes to use when trying to convert a blank stare into an "a-ha!".

    Beyond this, what is necessary is that less experienced developers (in a rapidly expanding industry, these are surely a vast majority) have experience doing things badly, and doing things well. From this they'll learn.

    I have found The Pragmatic Programmer and other stuff from Andy and Dave (like the article) to be very accessible to less experienced developers and useful in my crusade to improve practices.

    Ian Mitchell, I share your frustration with hearing things that are presented as if they are new though I think the assumption that an article on Software Engineering will necessarily be chocked with ground-breaking edge-bleeding ideas is one that will need to be challenged more as the discipline and the profession matures.

    Moores law does not require a revolution in development practices every week - about the only thing that does is the hype engine that sells products to clueless IT Managers.

    I look forward to the day when the average age of a useful computer book is measured in decades and since the web I tend to prefer to buy books with better longevity for much the same reason. I look forward to the era beyond the big bang of the computer revolution towards consolidation. I think that era will be even more exciting.
  8. Ian, I just noticed you managed to remove a disconcerting mixed metaphor! "gardening with tracer bullets" isn't really as compelling as your use of a "stake in the ground".
  9. OK, I'll be the first to extend this analogy this way.

    I guess this is why when management wants the developers (the garden) to be more productive they shovel on the manure :-)
  10. Analogy of buildings v/s garden[ Go to top ]


    The software (as a product) and software management are two different things. A software application is more closer to building than a garden. A garden is closer analogy from project management perspective, I think.

    The building shape is not changed frequently because the expectations are very much defined in the beginning, which is not the case for Software. Also, changing the building shape is visible effort, while in software, everything is virtual:). It is not the software or software developer who is at fault, it is just that the expectations from the software are not realistic.
    But we will be at that point soon, when customer wants to change the shape of building (software) and it will be done fast enough to meet the expectations. Read this next move in programming:
  11. Gardens.[ Go to top ]

    I like the analogy around the garden, I can definitely relate to the concept that you start with something neat and tidy, then end up with something that can be different to what is expected. Also, continuing the gardening concept, if the garden is too large (as is in my case at home), then you'll never get full coverage and end up with some parts that are pretty disorganised. Recovering these can be the worst. Also, if you don't water enough, or don't use fertiliser then the plants will end up looking pretty dead. Further, if the soil is too hard, then the carrots end up being pretty curly and don't taste so good. In fact generally you should grow carrots in pots with soft soil so they end up nice and straight.

    You could hire a gardener to help you out as you are too busy at work......then the landscape architect to help design the thing in the first place - this is kind of expensive, and generally they don't like to get their hands dirty - but prefer to work with concepts.

    Anyway, I can definitely relate to the stratification of roles. As an architect, it can be pretty difficult to influence designers and developers sometimes due to lack of visibility of what is actually happening. Further, at this lack of visibility continues, one can find that the project can drift off in directions that are not always desirable.
    BTW. Has anyone read that UNIX book - the Magic Garden? Great read - very complicated.
  12. Gardens.[ Go to top ]

    I also like the analogy around the garden.
    Agile stuff is great as manure.
  13. Gardening concept[ Go to top ]

    I think depending on the tier you are working on,
    It's like doing a little bit of artwork, poetry (in something like lojban) and logic puzzles. I do like the garden concept because it implies evolution and the need to maintain and cope with unexpected situations...however, I don't think it is *that* out of control. The requirement changes end up killing certain plants rather than them dying on their own or looking different than what a developer expects. (you also have to deal with can use unit testing).

    Anyhow, back to artwork/poetry/puzzles. The poetry is in the syntactic choices available in the language. The artwork is a direct analog to UI building. The puzzles are solving problems step by step in middle tiers. It is also like sorting baseball cards too (you can sort by RMI/batting average, alphabetically etc) have to organize concepts into groups. (ie: namespaces, packages, classes, database tables). The artwork is becoming however more and more is just interactive artwork. Much of the details can be solved almost automatically in RAD tools.

    Artwork, novel and poetry writing also require a lot of the same type of personal space and concentration. Cube farms are not so good at doing software or writing novels.