Software Gardening: Software is Not a Building

Posted by: Craig Berntson , on 1/10/2014, in Category DNC Magazine
Views: 8207
Abstract: Comparing software development to constructing a building is wrong. This article discusses why construction is the wrong metaphor and that software is organic and changes in unpredictable ways

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.

software-triangle

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 next part of this article can be accessed in the 10th Edition of the DNC .NET Magazine

Give me a +1 if you think it was a good article. Thanks!
Recommended Articles
Craig Berntson is the Chief Software Gardener at Mojo Software Worx, a consultancy that specializes in helping teams get better. He has spoken at developer events across the US, Canada, and Europe for over 20 years. He is the coauthor of 'Continuous Integration in .NET' available from Manning. Craig has been a Microsoft MVP since 1996. Email: craig@mojosoftwareworx.com, Blog: www.craigberntson.com/blog. Twitter: @craigber. Craig lives in Salt Lake City, Utah


Page copy protected against web site content infringement by Copyscape


User Feedback
Comment posted by Henrik Eriksson on Saturday, January 11, 2014 1:51 AM
I've been into similar thoughts as you and actually spoke with a "gardener" about what he is doing. He promptly disagreed with my description of what I thought he was doing and said that was wrong. They are planning and building stuff as any other would build a house. He, in fact, said that gardening is more of building a house, it's just a matter of maintenance costs. And he would know since he started out with construction. How to deal with plants are as much planned as everything else, even plants have names of how long they bloom. They are even manufactured so they can keep a garden with bloom as much as possible. So basically a garden is planned into oblivion, if you are a serious gardener.

And actually large construction sites nowadays are building with agile ideas, with teams. Particular construction is actually paid in terms of sprints. What they do benefit from is that they can actually measure and predict the requirements, which we in the software industry cannot, yet, do. But even they are sometimes  struck by bad priorities :). I spoke with an software architect for a construction company and they are trying to keep large orders as close as they need it because planning it all up front is too expensive, so they will order it when they see they need it.

I'd say software engineering is neither but could borrow a lot from both construction and gardening since they are a lot older than our industry.
Comment posted by Matthew D on Saturday, January 11, 2014 5:18 AM
How do you handle scenarios in Agile where a project member suddenly falls ill/or moves out? Waterfall tends to be more secure as it is very plan oriented. SO even if a team member drops out of the project, it isn't a huge problem, as a new member can easily take the old one's place. Since there aren't frequent releases, the project doesn't suffer.
Comment posted by Roby on Saturday, January 11, 2014 5:37 AM
Been there, done that, I agree to most of the points highlighted in this article. It's well written. However at times I have felt that Waterfall tends to be best for static projects, where there aren't going to be many changes (although nobody knows at the beginning if the a project is going to be as static as it claims to be). Rather than outrightly rejecting a particular model and deciding which is right or wrong, I tend to focus on analysing the different components of a project and then decide which method is better suited to the project and your needs.

By the way, love the magazine!
Comment posted by Craig Berntson on Saturday, January 11, 2014 4:34 PM
Henrik, I agree that gardening takes planning. However, what if you've decided to plant corn and it's too expensive or you can't get the quantity you need? What happens if you get a drought and what you've planted can't survive? When constructing a building, how difficult is it to change the plan and do something different if requested or needs change? With a garden, it's much easier than with a building. Construction tends to be set in stone more than gardening. I have seen Agile used successfully in construction projects. If you read my current column in DNC Magazine (January 2014 issue), I talk about Agile being the Soil of software development. I think most projects will be more successful with Agile than Waterfall. That said, some require Waterfall.
Comment posted by Craig Berntson on Saturday, January 11, 2014 4:37 PM
Roby, Agile is designed to handle change, whether that be requirements change or a change of team members. If a team member leaves, it would be a user story that doesn't get completed on the scheduled sprint. I've been on Waterfall teams where team members moved off and it caused lots of concern regarding the schedule.
Comment posted by Ralf Westphal on Sunday, January 12, 2014 4:19 PM
If you start to think of software as being organic - you have to take into account death. And disease. And aging. And metabolism. And sex, or at least offspring ;-)

So where´s the customer who plans for the death of his software? They all want it to live forever. So we need to tell them that won´t work. The moment a software is born they need to plan for its death.

Also evolution does not happen within a single organism. Evolution happens over a series of organisms, that´s why the produce offspring one way or the other. That´s also why a customer needs to think about the life expectancy of his software.

Organisms come with a plan built in. That plan is unfolded by growing. They organisms live for a while without any further adaption. Then they die.

How does that fit the new analogy?
Comment posted by Craig Berntson on Sunday, January 12, 2014 5:19 PM
Ralf,

Good points. Software does die. I've heard that on the average, an application is rewritten by scratch every four versions. Sometimes there's good reason to support new technology or platforms. Other times it's because the code is unmanageable. That's part of what Software Gardening is all about. Writing code that can be enhanced and maintained without the need to rewrite so often. I will be addressing these issues in a future column.
Comment posted by James Velasco on Monday, January 13, 2014 10:11 AM
I agree with your article 100%, but there is a gaping issue which I have yet to see addressed (and for which I don't currently have a good solution for either): the huge impedance mismatch between the organic nature of software development and the static budgeting workflow of virtually all business who pay for it.

A client needs to know upfront what something will cost and how long it will take before they can get approval for funding, but yet we can't answer that until its built.
Comment posted by James Velasco on Monday, January 13, 2014 10:15 AM
I agree with your article 100%, but there is a gaping issue which I have yet to see addressed (and for which I don't currently have a good solution for either): the huge impedance mismatch between the organic nature of software development and the static budgeting workflow of virtually all business who pay for it.

A client needs to know upfront what something will cost and how long it will take before they can get approval for funding, but yet we can't answer that until its built.
Comment posted by Craig Berntson on Monday, January 13, 2014 1:49 PM
James,

You are correct. You can build in some budget for unknowns, but it's rarely 100% accurate. That's where Agile helps. You can see what's tracking to plan and budget and make adjustments as needed.
Comment posted by infotech system on Tuesday, January 21, 2014 3:08 AM
A customer needs to recognize advance precisely what some thing will definitely cost and also how much time it will take before they can get approval for funding, but yet we all are not able to response that right up until it's built.
Our website: IT consultants in gurgaon: http://www.infotechsystems.co.in/it_consulting.html
Comment posted by Clinton Gallagher @virtualCableTV on Monday, February 3, 2014 9:23 AM
I hold an architectural degree and worked as an architect for years before getting serous about software development pursuits. The design-build process used by architects in the construction industry is what developers call "agile." In fact each attempt to put a label onto the process of software development has come before in the construction industry and the process for each are mirrors of one another in many respects.


However, gardening?


Well, okay, I do tend to agree that the gardening metaphor does work rather well as once involved with the design and development of software I have learned that there are just as many worms leaving their sh!t around that is called fertilizer as any other endeavor I have observed.
Comment posted by Stephen on Monday, February 3, 2014 3:08 PM
Organic growth of software is something that we have practiced for decades; not by design or choice, but by the nature of the relationship with customers.

On the positive side, the customer ends up with a system that precisely fits their requirements, on the down side; the developer ends up with something that looks like a patch, on a patch, on a patch. This method does not yield a simple, clear, coherent model; it produces an intricate and difficult to maintain web of processes (no matter how well the code is structured). The customers gain is the developers cost.

However, the precision of fit produces internal efficiencies for the customer and this yields competitive advantages. The customer is always better off as a result of this type of development; the developer has the benefit of a client for life
Comment posted by Viktor Peacock on Wednesday, February 5, 2014 4:01 AM
You always need a concrete foundation to build upon. When it comes to developing any application, you start off with a framework and infrastructure layers. Once these are defined, you then enter agile mode and start developing the application. You may use waterfall and plan application a year in advance - there is nothing wrong with that. The hard bit is to design the system in such a way so that it can be easily re-structured, i.e. it will have organic structure. This is where a good separation of concerns is a key. If you are using a waterfall model and your separation of concerns is poor, then you'll fail in a disastrous way. However, if you are using agile, you'll probably still fail (earlier), but you would be able to recover relatively quick. Foundation must be in place, but it needs to be organic - you want to be able to move and replace components without taking down entire application.

Post your comment
Name:  
E-mail: (Will not be displayed)
Comment:
Insert Cancel