Johnathan had never purchased custom software in 20 years of business. But after months of searching for an off-the-shelf solution, he had given up. He was anxious to get things going and wondered how the process worked. He had decided to go with No-Glitch Software to do the work and their top programmer, Richard, would arrive in no time for their first meeting.
When Richard arrived, he was shown around the office and manufacturing floor to get a feel for how things worked, then they went to Johnathan’s office to talk about the process.
“Well”, Richard said, “creating customer software is a lot like construction of a building. We have to do some planning. This is similar to the blueprints and site planning. During this phase we’ll sketch out all the screens and reports and create a prototype. When that’s done, we’ll start the work, which is like that actual construction process. We’ll create everything then install it so you can do some testing. That’s when we enter the bug fix stage and finally, after that, you’ll be up and running. The whole thing should take about six months.”
The analysis process ended up taking longer than expected. Once the prototype was delivered and approved, No-Glitch Software was already a month behind schedule. Johnathan was surprised when the prototype code was thrown away and Richard started coding all over again. But the coding process seemed to be going well, at lease he assumed it was based on the bills he kept getting from No-Glitch.
Then, about a month before the test version was to be delivered, Johnathan learned that interface to the key piece of machinery had changed and that would require a change to his new program. He called Richard and he did not seem happy.
“That will require some major changes because the interface is a key part of the application and it is used in all over in the application. I estimate it will take an additional month.”
Does this all sound familiar to you? Have you ever compared software development to building construction? I have, but I don’t do it anymore.
There are a lot of things wrong with the above story. Let’s see if we can figure out what’s going on.
This article is published from the DotNetCurry .NET Magazine – A Free High Quality Digital Magazine for .NET professionals published once every two months. Subscribe to this eMagazine for Free and get access to hundreds of free .NET tutorials from experts
What is the problem?
For many years, I have heard software development compared to building a house or a building. A plan needs to be put into place, a good foundation, and solid walls that can support the roof. It will take months of work just to get a good plan ready before the real work begins.
The comparison even goes further. Software development even uses many of the same terms as construction. Both have architects, architecture, engineers, plans, contractors, scaffolding, design, etc. That’s not to say these words are bad. It’s the comparison between construction and software development that’s bad.
You see, construction has fixed rules and regulations. The plans are set in stone and are difficult to change. The problem is, construction is, with few exceptions, run using the Waterfall methodology. And this is bad for software as Waterfall does not allow change. It does not allow enhancements. Maintenance is difficult and best practices are difficult to follow.
When you use Waterfall project management in software it leads to code bloat, rotting code, rewrites, spaghetti code, bugs, dissatisfied customers, dissatisfied managers, schedule overruns, cost overruns, and technical debt. (I’ll discuss technical debt in more detail in a future column.) The bottom line is using Waterfall processes is like going over Niagara Falls in a barrel. Few people that did it, lived to tell about it.
Other problems with our story exist. First, the interface to the machinery was not isolated to a single area of the application. Time was also wasted on a prototype.
So, what are we to do? As a start, let’s change our definition. Stop comparing software development to construction and start comparing it to gardening.
A new definition
I first came on this idea about a few years ago while re-reading the book Pragmatic Programmer. When talking about refactoring, the authors said
Rather than construction, software is more like gardening – it is more organic than concrete.
As I started thinking about this and realized they were right. Software is organic. But the authors also didn’t carry this concept far enough. Gardening can be applied to many other areas of development, not just refactoring. I then started speaking about Software Gardening at conferences and code camps. The topic was hit. Many attendees came up to me afterwards and said the comparison was right. Some even said it was the best presentation of the conference.
Then earlier this year, I started reading the book Object Oriented Software Guided by Tests. In the forward, Kent Beck writes
What if software wasn’t “made”, like we make a paper airplane – finish folding it and fly it away? What if, instead, we treated software more like a valuable, productive plant, to be nurtured, pruned, harvested, fertilized, and watered? Traditional farmers know how to keep plants productive for decades or even centuries. How would software development be different if we treated our programs the same way?
After reading this, I was positive that I was onto something. After all, here is one of the great minds in software saying the same thing I have been saying for over three years. But I needed to spread the word to a larger audience. And thus, here I am, writing a regular column for the .Net Curry Magazine
Software is organic
So what does it mean that software is organic? Think about a plant. It grows and changes in unpredictable ways. It may change with the seasons. It may bear fruit or shade or beauty. But we also have to care for it properly. Think about what Kent Beck said in the above quote. We need to nurture, prune, harvest, fertilize, and water our software. We also need to remove the weeds, keep the insects away, give it light, the proper soil, plant the right seeds, and use the right tools. 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.
You are probably familiar with the software development dilemma. If not think of a triangle. One side is labeled time. Another is money. The third is either features or quality. The old saying is that you can have two of the three, so pick them. I propose that if you treat software as a Garden, you can have all three.
Software Gardening is about all this and more. I’m excited to be writing this new column and have it come to you every couple of months. Along the way I will talk about soil, light, water, pruning, weeding, tools, and more. Apply the concepts you will learn here. If you do, your software will be lush, green, and vibrant.
The other parts of this series are as follows:
Software Gardening: Using the Right Soil
Software Gardening: Watering Your Garden and Software Craftsmanship
Software Gardening: Light and Sunshine
Software Gardening - Storing Seeds (Software Branching Practices)
Software Gardening: Insecticide – Getting Started with Unit Testing using an ASP.NET MVC application
Software Gardening: Harvesting (Continuous Delivery Techniques)
Software Gardening - Agile is not for the faint of heart
Code Refactoring (Software Gardening - Pruning)
Object Oriented Programming (Software Gardening - Seeds)
Single Responsibility Principle (Software Gardening: Seeds)
Open-Closed Principle (Software Gardening: Seeds)
SOLID: Liskov Substitution Principle (Software Gardening)