Software vs. Civil Engineering

How Software Engineering is radically different from Civil Engineering, and why confusing the two is so dangerous and costly.

Software developers like to call themselves engineers.  I admit, that I have referred to myself as a software engineer on more than one occasion - though in recent years I have come to believe that this identifier is both inaccurate, unproductive, costly and even dangerous to our industry.

It is empowering to think of ourselves as "engineers".  It gives us a credibility that is not conferred by the title "developer".  But it also categorizes what we do in a way that I believe, in many cases, leads to poor software design, and messy systems implementations.

How Civil Engineering is so different from Software Design
I read an article some time ago by Chris Aitchison called "You are not a software engineer".  It was the first time I had read someone else describe why they thought the term "Software Engineer" was an inappropriate term for what we do - and I think that it provides a fantastic metaphor to replace it.

I've spent a lot of time thinking about this issue though - and would like to expand on what he wrote, and to provide an alternate explanation of how we might approach software design that is more effective.

Building a Bridge, or a Skyscraper, or a Road requires a massive amount of planning up front, and detailed specifications - before the project begins.  One of the major reasons that such detailed plans are needed up front is that changes to these types of projects, once the project has begun, are generally very expensive.  In some cases, prohibitively so.

One can not start building a 50 story skyscraper, then decide to change it to a 100 story skyscraper 80% of the way through the project.  This is simply not done.  It would, in almost every case be both cost prohibitive, as well as being physically unfeasible in most cases as well.

Software, however, is a completely different animal.

Don't get me wrong - I am NOT arguing that planning should not, or does not need to be, a central part of the software design process.  But, that being said, what I am arguing is that the approach to software design and implementation can be done in a radically different way than a civil engineering project - because of the nature of how software works.

Often, with a physical engineering project, models are created up front to show the client what the final product will look like.  Small scale version, or prototypes might be created to work through some of the physical aspects of how certain parts might work together.  (Obviously much of this is now done "virtually", with the help of computer aided design (CAD) programs - but that doesn't change the underlying point here).  These prototypes and models however are not generally functional thought, and have no bearing on the final project that must be delivered.

In other words, it is not possible to create a 1/10th scale version of a skyscraper, and then "scale it up" to full size.  It is not, generally speaking, productive to create a bridge "iteratively".  Building physical structures simply do't work that way.

Software, by contrast can, and more and more these days, is developed iteratively.  Software can evolve.  Software can grow.  If you design a house, and want to change the footprint of the house, this would require you to pull down the existing structure, pouring a new foundation, and then building a new house.  In software design, this is often not the case!

A different approach
Thinking of software, as though it is cost constrained in the same way as physical engineering, leads us to approach software as though it is a civil engineering project.  We want "full functional specifications", blueprints as it were, before starting the project.  We then expect to be able to climb into a cave for 4-6 months, and come out after that time with a finished product that exactly implements the desired functionality, "to spec".  Then, when the client looks at the final product and decides that they don't like 50% of it, the entire process repeats itself.  Implementations go over budget (on both time and cost), clients are left unhappy, and ultimately - projects fail.

The agile development methodology is designed to address this to some extent, but ultimately, what is needed is a more fundamental shift in our perspective of what software is, and how it should be developed.

Software is not a physical structure, and can be changed, cost effectively, in a way that makes it fundamentally different than anything that human kind has created in it's history.  We should take advantage of this flexibility in our approach to it, from the top of the design metaphor, all the way down to the individual developer, working on a single widget within the larger project.

Software can, and should...evolve.  It should grow.  This is why the description of us as software "gardeners", is a much better description of us than software engineers.