This post was written by Richard Clark, Chief Product Officer at Provar. For more on Richard, please visit him on LinkedIn.
While sitting in the garden digging out yet another patch of snowbells (white garlicky bluebells, if you’re not familiar), I had an epiphany as I sat on the ground, sweating away in the spring sunshine.
“Gardening is a lot like application development.”
My first thought was that this was probably a well-known analogy already – after all, we talk about fixing the root cause, we talk about bugs, but I had to dig for it (yes, deliberate pun, sorry). While there are even some books and articles on Software Gardening, what I found interesting was how quickly some other authors preferred construction or craftsmanship as an analogy. I think that’s a very näive opinion, aspirational rather than reality.
So why are gardening and coding similar?
Observation
Gardening: You first see a weed by observing it unless you have some fancy gadgets that look under the soil.
Coding: Most bugs are first reported when a tester or user sees them. We can also find bugs from scanning code and systems; we add this to our technical debt pile to fix later if they’re acceptable.
Acceptance
Gardening: While the weed may be unsightly or undesirable, it only requires immediate action if it’s poisonous or impacting other plants.
Coding: We prioritize bugs to fix the serious ones first. Security issues are equivalent to poison; they need careful handling.
Resolution
Gardening: I can remedy the visual aspects of a weed by pulling up the leaves and flowers, and I can even think that I’ve removed the issue by doing that, but most plants will grow back unless I dig out the roots.
Coding: I can resolve a bug by changing how it appears or changing code so that it doesn’t appear under the same set of steps to repeat, but unless I fix the root cause, it will come back.
“It’s a feature”
Gardening: A weed is any plant growing where you don’t want it. Sometimes, we encounter something we didn’t plant, but if we like it, we keep it.
Coding: We’ve all heard the saying, “It’s not a bug. It’s a feature,” but joking aside, sometimes a bug can cause more desirable results than intended, such as restricting access to PII data.
Scaffolding
Gardening: Where we want a plant to thrive, we sometimes build a structure, be it a trellis, canes, or wires to climb into the desired shape.
Coding: Many development frameworks leverage scaffolding solutions to template the solution and ensure the code is developed along specific limited paths.
Pruning
Gardening: We prune plants to shape them but also to remove parts we don’t need that are consuming limited resources.
Coding: We should prune code to remove unused elements, large comment blocks, or obsolete procedures.
Buy vs build
Gardening: I can buy vegetables and herbs from a grocery or grow them with the right resources. It’s cheaper to buy some when I use them rarely, but cheaper to grow ones I use most often or are easy to maintain.
Coding: I can build code if I have the right resources, or I can use an external service. Using a service, I only pay when I need it, whereas I need to maintain resources (infrastructure, people, tests) to keep my code whether I use it or not.
End of life
Gardening: Some plants only last a season, and others live many years, but ultimately, they will no longer be as productive and reach the end of their lifespan. You must tear up the plant and replace it with something more suitable.
Coding: Refactoring code is a critical tool in maintaining the longevity of solutions. Sometimes, that means a complete rewrite or replacing our homegrown solution with a vendor product.
Effort vs reward
Gardening: If you put more effort into looking after your plants, AND YOU KNOW WHAT YOU’RE DOING, your plants will thrive, live long, and bear fruit.
Coding: If you put more effort into looking after your code, AND YOU KNOW WHAT YOU’RE DOING, your code will thrive, live long, and pay back the effort many times.
Bad actors
Gardening: If you let someone loose in your gardening who doesn’t know what they’re doing, it can all go wrong. They can dig up the wrong plants, water the weeds, and prune; your garden would die.
Coding: If you let someone loose in your codebase who doesn’t know what they’re doing, it will all go wrong. They can delete the wrong code, introduce new bugs, impact performance, and introduce security issues. There’s a good reason we let developers work in sandboxes and shadow environments!
Size matters
Gardening: The bigger the garden, the more manpower you need to look after it and the more help you need to see what may be wrong. Skilled tasks require specialists, but any trained individual can perform many tasks. Start with manual tools and add power tools. For repetitive activities, you add automation – perhaps lawn sprinklers, pumps, and robot mowers.
Coding: The bigger the application, the more manpower you need to look after it and the more help you need to see what may be wrong. Highly skilled tasks require specialized individuals, but trained individuals can perform many tasks. Start with coding and testing manually, then add automation later for regular activities, like code scans, formatting, and test execution.
Satisfaction
Gardening: When your plants flourish, your lawn edges are straight, the grass is mown, and the beds weeded, you can stand back and enjoy the sights until tomorrow.
Coding: I get a massive sense of accomplishment when adding a new feature, testing it, and getting zero bugs back from my scans, unit tests, peer reviews, test automation, and exploratory test results. It does happen, though not as often as I’d like!
Don’t I Want to Talk About Testing?
Ah, thank you for asking. Yes, because we can all see when a garden is thriving and doing well because our eyes and brains work exceptionally well at processing the images we see. The issue is when it comes to software, we need to augment our perceptions, and that’s where software testing and quality assurance come in.
It is vital to choose tools that help you validate your applications through their entire lifecycle, track design decisions, record results, run regular tests, monitor production, and put all those results visually in one place so we can make informed decisions about our application’s health.
The Provar Manager can help with this. Learn more about Provar Manager and reach out about a free 30-day trial today.
