At Made Tech we deliver successful outcomes to our customers, and within my delivery team we contribute to this by delivering quality software. As a lead engineer, I’m on the lookout for techniques that build our confidence in the software, for adjustments that we could make to our test strategy and culture, and for how we can implement these changes in our teams. This is why, one Tuesday evening earlier this year, you would have found me watching a talk by an ex-colleague which was enticingly titled TDD and other drugs.
While the talk is more broadly a look at the importance of testing, it was the motivation-of-people section that got my mind running on a bit of a tangent. That feeling of mastery you experience as a developer, the sense of building a masterpiece as it falls into place, coupled with the more holistic notion of thinking about the code-base and the team as a system, led me to think of our software as beautiful, well-maintained gardens. I couldn’t immediately explain my rationale for this – it just made sense to me. But after giving it some more consideration – with a bit of gardening research thrown in – I’m convinced! Here’s why…
Gardeners versus programmers
The first edition of The Pragmatic Programmer (which now has a 20th anniversary edition) coined the idea of software craft as its very first tip: “Tip 1 Care About Your Craft”’. This means that as developers we have scope for flair, individuality, interpretation and love in our work. This formed the foundations for a more formal approach to “software craftsmanship” which even comes with its own manifesto and builds on the 4 agile values.
Like software development, gardening is also a skilled trade, a form of art, a craft. Programmers and gardeners spend years honing their abilities, learning new techniques, finding new tools and applying them in their day-to-day lives.
Gardens versus software
Software and technology are both continually evolving and changing. They are organic, living organisms. Sometimes we build software that takes hold and really thrives, but sometimes – perhaps more often – we try to build something and it doesn’t quite work out or evolve as we expect.
Perhaps it needs a bit more thought, a tweak in its behaviour or maybe it is best just to stick it on the compost heap, and this is OK too. In this sense, software development can be just like a garden. We also need to react to changes in conditions, evaluate the environment and choose the correct tool for the job-in-hand.
Landscaping versus design
Becoming an architect is a well-trodden career path for gardeners and software engineers alike (but it’s not for all of us according to the creator of the super-useful C4 model who also argues that we should consider development more strictly as engineering than craft). When we take on a new software project we make some decisions at a high-level about how we expect it to look, which components flow into each other, what foundations need to be put into place to enable us to begin.
But this up-front work is just one aspect of software design, one aspect of landscaping. In building good software, we continually practise clean code, we make the software easy-to-change, we allow the architecture to evolve as we learn about that immovable root which was prehistorically planted to trip us up. We consider the potential risks around security, performance, and scalability in the way a gardener might think about the effects of sunlight or adverse weather conditions.
Maintenance versus … maintenance?
Software can rarely be completed and left untouched, in the same way that a garden can’t just be finished. There is always some level of maintenance to perform and certain areas require more maintenance than others. In the normal day-to-day of feature development, we are continually refactoring – splitting a method that has become too big, renaming a class, abstracting a local concept based on what we learn and what we know at the time.
Less regularly, we may repair some code – play down some technical debt or perform a minor restructuring. These activities may be akin to weeding (very often), mowing, pruning, or pollarding (less often). With legacy systems in particular we may have some instrumental components that require little-to-no maintenance. They don’t need touching and do the job well enough, but when they need work it may be an expensive investment so it becomes an effort vs value exercise, like removing a tree or replacing a fence.
Coming clean
I thought about titling this blog post “Why software engineers should make really good gardeners” but I hope to be the exception that proves the title true. So here goes. I am pretty terrible at gardening and have often wondered why.
After spending some time writing this article, I have realised 2 main reasons – unlike my approach to software engineering I don’t have enough passion and I don’t have enough discipline for the art of gardening. I let it grow away from me, prioritise other activities, try but don’t commit, or just make a good old-fashioned excuse because it feels too much like a chore.
So if you come to me and ask if we should make that manual fix at the expense of automation or skip the tests because it’s quicker I will slap your wrist, but if you tell me that No Mow May should be extended for the whole summer, you might get more than you bargained for!
