Why software program engineers make actually good gardeners

At Made Tech we ship profitable outcomes to our clients, and inside my supply crew we contribute to this by delivering high quality software program. As a lead engineer, I’m looking out for strategies that construct our confidence within the software program, for changes that we might make to our check technique and tradition, and for the way we will implement these modifications in our groups. Because of this, one Tuesday night earlier this yr, you’ll have discovered me watching a chat by an ex-colleague which was enticingly titled TDD and different medicine.

Whereas the speak is extra broadly a have a look at the significance of testing, it was the motivation-of-people part that bought my thoughts operating on a little bit of a tangent. That feeling of mastery you expertise as a developer, the sense of constructing a masterpiece because it falls into place, coupled with the extra holistic notion of serious about the code-base and the crew as a system, led me to think about our software program as stunning, well-maintained gardens. I couldn’t instantly clarify my rationale for this – it simply made sense to me. However after giving it some extra consideration – with a little bit of gardening analysis thrown in – I’m satisfied! Right here’s why…

Gardeners versus programmers

The primary version of The Pragmatic Programmer (which now has a twentieth anniversary version) coined the thought of software program craft as its very first tip: “Tip 1 Care About Your Craft”’. Which means as builders we’ve scope for aptitude, individuality, interpretation and love in our work. This fashioned the foundations for a extra formal method to “software program craftsmanship” which even comes with its personal manifesto and builds on the 4 agile values.

Like software program growth, gardening can be a talented commerce, a type of artwork, a craft. Programmers and gardeners spend years honing their skills, studying new strategies, discovering new instruments and making use of them of their day-to-day lives.

Gardens versus software program

Software program and know-how are each regularly evolving and altering. They’re natural, dwelling organisms. Typically we construct software program that takes maintain and actually thrives, however typically – maybe extra typically – we attempt to construct one thing and it doesn’t fairly work out or evolve as we anticipate. 

Maybe it wants a bit extra thought, a tweak in its behaviour or possibly it’s best simply to stay it on the compost heap, and that is OK too. On this sense, software program growth may be identical to a backyard. We additionally have to react to modifications in circumstances, consider the atmosphere and select the right software for the job-in-hand.

Landscaping versus design

Changing into an architect is a well-trodden profession path for gardeners and software program engineers alike (however it’s not for all of us in accordance with the creator of the super-useful C4 mannequin who additionally argues that we must always think about growth extra strictly as engineering than craft). Once we tackle a brand new software program challenge we make some selections at a high-level about how we anticipate it to look, which elements circulate into one another, what foundations have to be put into place to allow us to start. 

However this up-front work is only one facet of software program design, one facet of landscaping. In constructing good software program, we regularly practise clear code, we make the software program easy-to-change, we enable the structure to evolve as we study that immovable root which was prehistorically planted to journey us up. We think about the potential dangers round safety, efficiency, and scalability in the best way a gardener would possibly take into consideration the consequences of daylight or antagonistic climate circumstances.

Upkeep versus … upkeep?

Software program can hardly ever be accomplished and left untouched, in the identical approach {that a} backyard can’t simply be completed. There’s at all times some stage of upkeep to carry out and sure areas require extra upkeep than others. Within the regular day-to-day of characteristic growth, we’re regularly refactoring – splitting a way that has change into too huge, renaming a category, abstracting an area idea based mostly on what we be taught and what we all know on the time. 

Much less frequently, we could restore some code – play down some technical debt or carry out a minor restructuring. These actions could also be akin to weeding (fairly often), mowing, pruning, or pollarding (much less typically). With legacy methods specifically we could have some instrumental elements that require little-to-no upkeep. They don’t want touching and do the job effectively sufficient, however after they want work it might be an costly funding so it turns into an effort vs worth train, like eradicating a tree or changing a fence.

Coming clear

I thought of titling this weblog submit “Why software program engineers ought to make actually good gardeners” however I hope to be the exception that proves the title true. So right here goes. I’m fairly horrible at gardening and have typically questioned why. 

After spending a while writing this text, I’ve realised 2 principal causes – not like my method to software program engineering I don’t have sufficient ardour and I don’t have sufficient self-discipline for the artwork of gardening. I let it develop away from me, prioritise different actions, strive however don’t commit, or simply make a great old school excuse as a result of it feels an excessive amount of like a chore.

So if you happen to come to me and ask if we must always make that guide repair on the expense of automation or skip the checks as a result of it’s faster I’ll slap your wrist, however if you happen to inform me that No Mow Could must be prolonged for the entire summer season, you would possibly get greater than you bargained for!