Software is Not a Building (Software Gardening)

Posted by: Craig Berntson , on 1/10/2014, in Category Software Gardening
Views: 51019
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 (DNC) Magazine – A Free High Quality Digital Magazine for .NET & JavaScript professionals published once every two months. Subscribe to this e-Magazine for Free and get access to hundreds of free Development tutorials from experts.

 

Software Development - 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.

Software Building

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.

Software development - 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 other parts of this series are as follows:

Software Gardening: Project Management (Using the Right Soil)

Software Gardening: Software Craftsmanship (Watering Your Garden)

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)

SOLID: Interface Segregation Principle

Dependency Injection - SOLID Principles

Coding Guidelines - Important for Developers

Reduce Bad Code with Code Reviews

Revisiting SOLID principles

This article has been editorially reviewed by Suprotim Agarwal.

Absolutely Awesome Book on C# and .NET

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

What Others Are Reading!
Revisiting SOLID principles

Reduce Bad Code with Code Reviews

Coding Guidelines - Important for Developers

Dependency Injection - SOLID Principles

SOLID: Interface Segregation Principle (Part 4)

SOLID: Liskov Substitution Principle (Software Gardening)

Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+

Author
Craig Berntson is a software architect specializing in breaking up the monolith and improving developer teams and processes. He is the author of two books on software development and has been a speaker at conferences across North America and Europe. He received the Microsoft MVP award twenty-two straight years. He lives in Salt Lake City, Utah.


Page copy protected against web site content infringement by Copyscape



Feedback - Leave us some adulation, criticism and everything in between!
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 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.
Comment posted by Craig Berntson on Tuesday, May 6, 2014 9:53 AM
Sorry for the late reply here:

@Clinton - I'm not the only one that has applied gardening to software. The first I can think of is Dan Briklin, the creator of the world's first spreadsheet, Visicalc. His current company is "Software Garden".

@Stephen - patch on patch on patch is not software gardening. Have you ever had to patch a hole in a wall? Often, you end up patching the patch because it wasn't done correctly the first time. In a future column, I will address refactoring. Done properly, refactoring will not look like a patch. I once heard a quote from a famous computer scientist (alas, I can no longer find it to properly attribute it), but it went something like, "Once you get done writing code, rework it so it looks like you knew what you were doing all along".

@Viktor - A good foundation is very important, but often you don't have that to start with. Most of the work we do as developers is maintaining existing applications, often times we inherit an application with a poor foundation.