Software Gardening: Yet Another Crappy Analogy or a Reality?

Patroklos Papapetrou, @ppapapetrou76

Introduction

The debate about how close is software development to engineering started a decade ago [1]. People started to realize that writing software has very little to learn from math and engineering [2], but we couldn't find something else to compare it with. The first article [3] I can find on the internet talking about software gardening is actually an interview with Andy Hunt and Dave Thomas, the authors of The Pragmatic Programmer: From Journeyman to Master, back to 2003 with. Fortunately, some years later more articles appeared discussing the same analogy and more people got exposed to the strange term of software gardener.

To be honest, I was expecting that software gardening movement would have become as popular as the agile manifesto but I was wrong. This is one of the main reason I decided to write a book about it. In this article I will tell you my short story and how / when I realized that I am a gardener and not an engineer. I will also briefly explain the analogy of software development and gardening and present how it is compared with agile development and software craftsmanship.

The story of my (developer) life

I would love to start my story by telling you, that, when I was a young and inexperienced developer, I had mentors who taught me how to write clean code, but I can't. The ugly truth is that learned the hard way how to treat code as flowers. And that is the second reason that made me write the "Art of Software Gardening" [4]. One of the core values of a software gardener is being a mentor. Sharing our experience and our acquired knowledge should be a part of our attitude. And this is what I want to teach to (junior) developers through my story and my point of view.

In the beginning of my career, back to 1997, I was a very passionate developer, like most developers are or should be when they start writing code. The tools that we were using that era - PowerBuilder, Visual Basic and Delphi - look like dinosaurs today comparing to the modern IDEs and the cool frameworks and libraries that appear almost every day. However, the principles of software development are still the same and I will dare to say that they will hardly change in the future. My only goal, when I was writing code, was to finish my assignments as soon as possible and of course without any bugs. I wanted to prove to my employer that I deserved every single drachma they were investing on me. Funny huh? We all want the same! I remember, one time, how proud I felt, when my supervisor, looked so surprised that I had completed that sexy new feature we wanted in just a couple of days.

"Did you test it?", she asked me while she was trying to make sure that I hadn't only created the user screen but all those buttons and fields were doing what they were expected.

"Of course I did!", I replied with pride. I hope you don't expect to read in this article what kind of unit testing framework I used. The first XUnit framework appeared some years later, in 2002. So, I was manually testing my code by wearing the end-user hat. Clearly, it was extremely difficult to predict all the possible ways that a user might interact with the system and my efforts were limited only to what I was understanding as a developer. This is what we called "testing", twenty years ago.

My professional life was rolling quite well. Some bugs were always expected and they were considered acceptable(!) if customers discovered them when using the system in production. We were a team of 5 developers. Most of the time we were working only on our code and I was so happy I could focus on my goal: be the fastest code monkey. One day, however, something strange happened that completely changed they way I was perceiving software development. One of the two senior software developers - oh yes, senior developers did exist that ancient period - wanted to slightly modify a feature I implemented, after a customer request. Typically, I should have done it, but I was deeply involved in another feature and she didn't want to interrupt me. Besides it was a quick improvement that shouldn't take too long. I still remember that look of her face when she asked me to explain my code. Actually this question was a trap. She was not only experienced enough to understand the code of some newbie like me, but she could also see things that I had never imagined that exist. In the beginning I felt so proud. "I have the chance to describe my precious code to the most experienced team member", I thought. "This is my chance to let her know that I rock!". Very quickly, that feeling was replaced by embarrassment, disappointment and ... failure! I was listening for more than ten minutes her criticism: "Lots of duplicated code, bad variable and function names, no clear separation of layers, large chunks of complicated code and most important. I have to re-write most of it in order to add that little feature our customer wants". Oh God, please help me disappear!

Suddenly, a whole new world was in front of me. Concepts that I wasn't familiar with started jumping in my head. I realized that she wasn't satisfied at all with my crappy code, although she was very gentle when she was explaining his findings to me. And that was my first experience with "clean code" but don't be fooled. I didn't changed the way I was programming from one day to another but that criticism was a shock to me. It was the first time I was feeling, development-speaking, so nude. It took me a couple of more years to start really caring about the quality of the code I was writing and even more to embrace the values and principles of software gardening.

Agile vs Gardening vs Craftsmanship

Obviously, software gardening deals with the issues discovered in the case above but it's much more than just slinging "good" code. The most important problem I was facing, had to do with the fact that I didn't really care about the code I was putting in the system. Let me remind you once again what my goal was to be the fastest code monkey. I didn't care about who would be reading it, maintain it, who would be using the screens I have created and how my code would behave when new features would be added in the system. I was just doing my - what I considered - "job", and then I was turning my back to the code forever. Like what engineers do. They build a house and then you never see them again. But we are not engineers any more. We do care about our code and we will be there to keep it clean and improve it as long our customers need and use it. Right?

I will come back to that later because I want to explain the relation of software gardening with agile practices. Many people ask me if software gardening is just another way of describing the agile movement and they try to compare those two. I want to make clear that software gardening is not competing agile values at all. It's very likely that you have already read the agile manifesto [5] and you know what it represents. The key point here is to understand that software gardening not only makes it much easier to embrace and adopt the agile practices but also takes them to another level. Why? Because agile practices are based on the way we treat software and we, the software gardeners have already changed our mindset. We already care about the code and the majority of the agile principles seem so natural to us. You can be a brilliant software gardener even if you are developing software using Waterfall or any other monolithic process, but you work in an agile environment it's most probable that you will easier and sooner achieve perfection.

There's one more thing I want to clarify about software gardening and it has to do with "Software Craftsmanship". One might wonder what is the difference between those two definitions. Here's the definition as taken from the recent book "Software Craftsmanship" by Sandro Mancuso:" Software craftsmanship is a long journey to mastery. It's a mindset where software developers choose to be responsible for their own careers, constantly learning new tools and techniques and bettering themselves. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development". Although I agree with most of the principles presented in that book and in general the idea of software craftsmanship, I believe that writing code is far more than a craft. A crafted software sounds to me more like an object. It might be very carefully designed, of high quality and made by the best materials but it's still an object. I prefer perceiving source code like flowers and software systems like gardens. Software systems live as long as people use them. They need to change, to evolve, to adapt to external and internal environment needs like gardens. You can't add a new level between the 23^rd and the 24^th floor of skyscraper unless engineering has evolved a lot the last few years. Last time I checked it was impossible. You can't just replace a pair of old or broken bridge pillars. You need to replace the whole bridge. But in software you can add a new layer or replace a module using old technology with a modern one. Because software is like gardening. By treating software as something organic, we expect change. We learn how to care for it so that when that change comes, we're ready for it.

The software gardener manifesto

So it's time to explain what software gardening is. Here's the definition I prefer.

Software gardening is not a practice, an attitude, a skill or a special knowledge. It's all of them plus the love you have for software development. And this love you should show it continuously, every day, in every single line of code you write.

Software Gardeners are professionals who perceive software development in a different way. Our goal is to spread the word of our core values, be mentors for the new developers and create software that it is developed at the highest quality bar. Every software gardener believes and embraces the following Software Gardener Manifesto [6]:

• We treat software systems as gardens and code as flowers. Although we don't disagree regarding software as a "craft", we believe that software is a living and breathing "being", not just an object, created using the best materials.
• We constantly mentor young developers and we share our knowledge at every opportunity. Junior developers are like flowers that need to be irrigated to blossom. We are the water, the sun, the oil, the fertilizer for every (young) software professional.
• Software development is a lot more than slinging code. We know the practices and we apply them effectively. We make use of the most productive tools and our skill-set includes both soft and technical skills. We also understand that our overall attitude is what defines us as software gardeners.
• We care about our code and we show this care continuously, day by day, every moment in every single line of code we write.
• We are not only able to respond to change but we are prepared about the endless - internal and external - environment reform.
• We treat customers as the people who will walk in our garden will smell and enjoy our fragrant flowers. Having said that we engage them from the first day, to make sure that all their needs, requirements and expectations will be met.
• Gardening is a team sport. There's no room for lonely cowboys like Lucky Luke or epic heroes. We work as a team, we respect the team, we embrace collaboration at its highest level.

Explaining the analogy

Let me give some examples that will make the analogy even clearer. Gardeners don't just plant some flower seeds today and expect to see them blossom tomorrow. Flowers needs their time and the proper environment (soil, sun, temperature, water, fertilizer etc.) to grow. Software gardeners do the same with their code: they write some well-designed (correctly irrigated) code that will grow within the overall system. Our goals is quite simple. Deliver bug-free (no-disease), fully covered by tests (protected by future diseases) features that end-users would love to use.

Another parallelism that I love is about unwanted plants. Gardeners just uproot anything that's blocking their design or doesn't fit in the garden. Software gardeners do the same. We throw away, without any second thought, the code that's not needed (withered flowers) any more or is causing too much troubles (unwanted plants).

The last one is about environmental changes. Gardens have to cope with cold, wind, rain, snow and in some cases with extreme weather conditions. A typical hurricane can easily destroy a wonderful garden in less than two minutes. At the same time flowers and plants are threatened by warms and other bugs - oops that's the same word we use in software; I wonder why. Things are quite similar in software. We have to deal with changes in laws, with evolving customer needs, with new competitors that just launched some cool and attractive features or even with security attacks that can cause a huge catastrophe to our systems and make our customers lose confidence for ever. Internal environmental changes like bugs, people leaving the team, new frameworks and libraries and many more can easily cause the same mess.

I can go on with many similar examples that prove the analogy of gardening with software development but I prefer to keep some for my book. I want to finish this introduction to software gardening by presenting the four axis of a software gardener. We don't re-invent the wheel. We know what we need and we properly use it.

Practices: TDD, Code reviews, Automation everywhere (do you know any gardener that irrigates large gardens manually?), re-factoring.

Skills: We recognize that software gardeners equally need to have technical skills like being a clean coder, write meaningful unit testing, being polyglot (choose the right soil and fertilizer) and soft skills like being patient and self-learner, avoid multi-tasking, setting goals, being proactive and ready to adopt to changes as individual and as a team.

Tools: We pick not the "best" tools but the tools that make sense to our team, our mentality, our project our company. We recommend however at least the following set of tools to be used: issue tracking systems, advanced source control management systems, wiki, code review tools, continuous integration, continuous delivery and continuous inspection systems, virtualization and like we already mentioned: automation everywhere.

Attitude: Maybe this is what it makes that huge difference between a software developer and a software gardener. Software gardeners are committed to their profession - or should I call it passion? They share their knowledge to the community. They never keep it for themselves. By the way how many bridge or skyscraper engineering conferences do you know around the world? They love being mentors, they pursue constructive feedback and they accept criticism to be better gardeners.

To be continued...

I really hope that this article proved that software gardening is not just yet another crappy analogy but a reality in software development. The world (including us) deserves much better software and it seems that we are still missing something. Maybe viewing our industry as gardening and not like engineering or craft might be the secret ingredient to success. Who knows? I believe it and many people believe it. All we have to do is spread the word, embrace the software gardening manifesto and build better software!

If you want to embrace the software gardener's practices and attitude I kindly invite you to sign the manifesto [6] and be part of this new philosophy and practical approach of software development.

References

1. Bridges, software engineering and God https://blog.codinghorror.com/bridges-software-engineering-and-god/
2. Why building software isn't like building bridges @ blogs.msdn.com
3. Programming is gardening, not engineering https://www.artima.com/intv/garden.html
4. The Art of Software Gardening, https://leanpub.com/art_software_gardening
5. The Agile Manifesto, https://agilemanifesto.org/
6. The Software Gardener Manifesto

---

More Methods & Tools articles on software development culture

Making Your Culture Work with Agile, Kanban & Software Craftsmanship

Laws for Software Development Teams

---

Click here to view the complete list of archived articles

This article was originally published in the Summer 2015 issue of Methods & Tools