I've been slowly acquiring an enthusiasm for gardening over the past few years, and so I was heartened to see Donna Benjamin liken software development to landscape design a month or so ago:
You also need to know what the maintenance resources will be. Will this be watered and tended daily? What about budget? Can we afford established plants, or should we plan to watch the garden grow from seeds or seedlings? The key point of comparison, is that a garden, whether big or small, is a living thing. It will change....
The idea has been around for much longer, though, and much more recently Janet McKnight pointed me to a 2011 blogpost that declared "you are a software gardener":
Do you try to plan your gardens in such detail that you know where each leaf will be positioned before you plant a single seed? Do people expect estimates (or are they promises in your organisation?) on exactly how many flowers will have bloomed in one years time? Do you have a bonus tied to that? Things that would be perfectly reasonable to plan for a skyscraper seem a little ridiculous when you are talking about a garden.
Apart from anything else, these discussions have helped crystallize two worries I've had for ages about comparing "software engineering" to civil engineering; or to even more straightforward, physical-construction projects. These worries attach the project from opposite directions:
- Building regulations In software, there are no such rules. Any standards we tend to claim for code (e.g. HTTP) usually cover its external behaviour, not its internal implementation, and so with no regulations to guide previous developers then the existing codebase's "electrical wiring" could be a bodge job, or heavily customized, or entirely made out of copper piping because "that's what the framework required."
- Standardized builds Meanwhile, almost nobody wants to have built for them the software equivalent of a flat-pack or a prefab. While you could provide an entire estate of houses, each with the same conservatory, every software project contains demands for bespoke elements of varying shapes and sizes. Frameworks and the rest might be available off the shelf these days, but the implementations of particular or novel user experiences are not.
Software writing is inherently a more organic and pragmatic process than a loft conversion. Acceptance and empathy are becoming more important skills for someone writing software than typical engineering skills like precision, correctness, idempotency, or certification. Working in this industry needs to look less and less like building, and more and more like tending; caring for; shaping; weeding; pruning; mending; making do.
Besides, the very idea of being a software gardener, working within a software garden, managing software borders and software beds? The unglamour of it is delicious!
Edit: it turns out that there are more self-describing software gardeners than I first thought; there's even a software gardening manifesto!
