The Art of Software Gardening
A couple of years ago I read for the first time this article :“You’re NOT a software engineer“ and from that point it was clear to me that I couldn’t agree more with the expressed ideas. I was always comparing software development with engineering ( building bridges, building etc. ) and it looked quite a straightforward comparison. But that was until I read that article. Every time I read it I believe more and more that systems are gardens and source code are flowers and plants.
This article inspired me to start writing “The Art of Software Gardening“ , a book that discusses the essential skills, the proper attitude and the useful practices that modern developers should have in order to master the art of software gardening. While writing it, I decided to post to my blog some articles to allow potential readers have an idea of what’s inside and for me to get some early feedback. This article presents several examples about the analogy of comparing software engineering with gardening.(Partially) Explaining the analogy
So what do these two “professions” have in common? Let’s start by an essential soft-skill and some attitude examples
- Growing gardens is something that requires patience. You don’t just plant some flower seeds today and expect to see them blossom in tomorrow. This procedure takes time and while waiting to see the results you have to be there and ensure that everything is going as expected. For instance several flowers won’t grow up if they are over or under irrigated. Plant diseases, also should be controlled early or prevention actions should be taken before they are noticeable. The same applies when you write some new code. You have to be patient. It’s better to deliver a bug-free (no-disease), fully-covered by tests (protected by future diseases), and well-designed (correctly irritated) feature (flower) one or two days later than trying to deliver it today with a poor design, complex code and nothing to prove that’s working.
- Successful gardeners are committed to their professional in the essence that they don’t perceive it as a “task”. They give flowers every day, every moment their love and affection and they are rewarded for that, when the time comes. These emotions get back to them with a feast of beautiful colors and sweet smells. Love your job as a developer and be passionate about coding. Treat source code like a small kid that needs your attention and very soon you will see the advantages and the benefits : Clean, maintainable code (colorful flowers) and systems without bug-reports (fragrant gardens). Code is not your enemy. If you find yourself struggling writing a piece of software then think for a moment if you haven’t given from the beginning the right attention. Step back for a minute and try again … :D
- It’s very common that some times things don’t work like a charm. Some ugly plants are getting too big hiding the beaut, or you notice that several flowers are getting withered. Gardeners just uproot anything that’s blocking their design or doesn’t fit in the garden. Do the same with your code. It’s not the right time to be emotional so without any second thought throw away any code that’s not needed (withered flowers) any more or is causing too much troubles (too big / unwanted plants).
That was only the beginning and this article just put the little finger in the honey pot. As long as my free time allows more articles will be added to my blog post. In the meanwhile you can take a look at the contents of the upcoming book “The Art of Software Gardening“ and since nothing is finalized yet feel free to comment, suggest, argue and of course declare your interest and get notified for future updates and news. To give you a clue about how content is structured, most chapters of the book apart of a detailed and explained gardener – developer parallelism will contain real-world practical examples and ideas that will make you a better professional, a real software gardener.
To be continued…
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)