This is part 1 in a series on Software Gardening. As other entries in this series are posted, you’ll find the links to them here.

Part 2: Soil
Part 3: Water
Part 4: Light
Part 5: Seeds
Part 6: Preparing the Soil
Part 7: Insecticide
Part 8: Pruning
Part 9: Fertilizer
Part 10: Weeding
Part 11: Nurturing the Garden
Part 12: Tools
Part 13: Conclusion – Becoming a Software Gardener

This fall, I launched a new presentation called “Software Gardening”. It’s gotten lots of interest, for which I’m grateful. Much of the interest comes from people standing in line for the lunch pizza at events and the first question is, “What is Software Gardening? I’ve never heard of it before.” So, I’m starting a series of posts on what exactly is Software Gardening and how can you use it.

To understand why Software Gardening is good, think about the common comparison between software development and construction. You hear it all time and both use common terms such as build, architect, engineer, design, scaffolding, contractor, and plan. But the problems with comparing software to construction is wrong. Construction uses fixed rules, takes months of planning, with blueprints set in stone, making it difficult to make changes when needed.

Think about what it would take to remodel your home. If you want to add a bathroom, you need an architect, contractor, permits, and more. You need to think about things such as how to hook up the power, water, sewer, and heat. You need to pour a foundation, do framing, flooring, and roofing. The entire process is complicated. You can’t just keep running down to Home Depot for parts and tools.

The problem is that construction uses a Waterfall methodology and we don’t want that in software. Waterfall doesn’t allow for change, maintenance, enhancements, or best practices. And this leads to code bloat, rotting code, rewrites, spaghetti code, bugs, technical debt, dissatisfied managers, and dissatisfied customers. Using waterfall is like going over Niagara Falls in a barrel. It’s not something you want to do.gardening

Perhaps we should then change our definition. In the book The Pragmatic Programmer, the authors state “Rather than construction, software is more like gardening – it is more organic than concrete.” The authors then go on to compare one aspect of software development to gardening. But there is more to it than that.

Think about the old development triangle, You know the one, where you have cost on one side of the triangle, time on another, and either quality or features on the third. You tell your client that they can pick two, but not all three. Therein is the dilemma. Can you  keep costs low, stay on schedule, and maintain quality? I say you can, through Software Gardening.

Gardening requires a number of things, nurturing, pruning, fertilizing, planting, weeding, soil, seeds, light, water, tools, and more. In subsequent posts in this series, I’ll talk about these concepts and how they apply to software development. And as you read them, keep asking yourself, “Is my software gardening thumb brown or green?” And if you apply the Software Gardening concepts, your software will be lush, green, and vibrant.