Coding a garden

I used to believe in a ‘hard’ view of software development.

I insisted that the developers we hired were ‘engineers’ and I used a lot of mechanical metaphors. To me, it was pretty much a binary affair. Building software was like building a car or a rocket; many hard, cold parts that fit together optimally, or not.

Today, just a little wiser, I have widened my views beyond the purely mechanistic. It seems to me that creating software has also a lot in common with growing a living being or a garden. As the software grows, it evolves; it responds and pushes back. Vestigial structures are all around the codebase. There are weed patches that creep in the same places—every release.

I don’t ignore the reality that software is a logical affair, and many things are either right or wrong. But at the macro-scale level, when I zoom out away from the individual lines of code and API contracts, what is left is a lot more than just a neat arrangement of zeroes and ones. It is something elastic, malleable and strikingly organic.

I believe that ‘yuck’ reaction to this quasi-biological mess is partly behind the impulse of developers that cry for a re-write of the codebase. Blow it all up, re-start! Re-create an immaculate mechanism! If the product has already developed a regular heartbeat (it’s alive!), you should be very reluctant to bring out a demolition crew to blow it up to pieces. Instead, I’d pull out my shovel or trowel and start working the existing garden.