Gardening Your Applications

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.

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 really 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 through observing it, unless you have some very 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 around it.

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 making changes to 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 come across 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 for it to climb into the desired shape.

Coding: Many development frameworks leverage scaffolding solutions to template the solution and ensure the code is developed along certain 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 I can grow them myself if I have 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, others live many years, but ultimately they will eventually no longer be as productive and reach the end of their lifespan. You have to tear up the plant and replace it with something more suitable.

Coding: Refactoring code is a key tool in maintaining 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, then 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, then your code will thrive, live long, and pay back the effort many times over.

Bad actors

Gardening: If you let someone loose in your gardening that doesn’t know what they’re doing then it can all go wrong. They can dig up the wrong plants, water the weeds, over prune, and your garden would die.

Coding: If you let someone loose in your codebase that doesn’t know what they’re doing then 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 many tasks can be performed by any trained individual. 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 many tasks can be performed by trained individuals. 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, the beds weeded, you can stand back and enjoy the sights. Until tomorrow.

Coding: Personally, I get a huge 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 extremely well at processing 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 comes in.

Choosing tools that help you validate your applications through their entire lifecycle, tracking design decisions, recording results, running regular tests, monitoring production, and putting all those results visually in one place so we can make informed decisions to our application health is vital.

Provar Manager can help with this. Learn more about Provar Manager and reach out about a free 30-day trial today.