22 Jun

Why Software Development Will Never be Engineering

Category:UncategorizedTag: , :

I always find it rather interesting when academics try to quantify generalized metrics about software development.

Things like: per lines of code, there will be X number of bugs.

Statements like: it has been empirically proven that “blah” affects the development of software in some way “blah.”

These are all interesting thoughts, but software development will never conform to rigid engineering principles like many other engineering practices.  The longer I work in the field, the more and more I realize that software development has nothing to do with engineering.  We just happen to attend some of the same math classes in school.

Building bridges

One of the main arguments I hear people make about the current state of software development as an engineering practice is based around its relative maturity to other engineering fields.

There is a huge problem with this line of thinking.

The argument goes something like this:  “Engineering has been around for hundreds of years and has matured to the point where it is a measurable science, but software development has only been around in earnest for the last few decades or so, therefore it is relatively immature as an engineering discipline.”

On the surface this argument seems sounds.  And certainly in 50 years software development will be different than it is now.  Heck, it is much more different than it was just 10 years ago.

But, here is the problem.  We build much more software than we do bridges.


Let me give you an example that came to light in another area of my interest… poker.

The poker quickening

An interesting thing happened in the poker community in the last 10 years; poker pros with decades of experience started getting beat time and time again by 19 year old poker prodigies.

From an outside perspective it looks like the poker world opening up just widened the search for talent and there it was.  But, a closer examination of the evidence leads to the truth.

Before the online poker industry was born, poker was played in card rooms and casinos in states where it was legal and occasionally at small home games throughout the US.

A poker pro might play poker tournaments perhaps 100 times to 150 times a year.  The sum knowledge of the poker community and the meta game around it was based on this base of professional poker players playing tournaments and gaining experience at this mediocre rate.

Once the internet poker rooms started opening up, things changed, and they changed rapidly.  Now anyone could play poker from their home PC.  Not only could they play poker, they could play poker tournaments at all hours of the day.

Here is a list of some of the major changes that took place:

  • Hands are dealt at 60-80 hands per hour instead of 10-30
  • Players can play in many tournaments at one time, 10 tournaments at once is not unheard of
  • Players can analyze hand histories and historical data about their play and opponents play through the use of software
  • Age requirements are out the window, technically any one of any age could be playing online
  • Players can play 24 hours a day
  • The professional online tournament player could easily play over 3000 tournaments in a year, while a brick and mortar pro would be lucky to reach 100 in a year.


So where am I going with all this?

The point is that as a whole more hands were dealt and more poker knowledge and experience was obtained in 1 year of online poker than probably the entire history of poker before that.  We reached such an accelerated pace of play that all previous knowledge of poker became obsolete. 

The strategy of tournament poker completely changed.  The game evolved perhaps 500 years into the future in a matter of 5 years time.

The same has happened with software development.

Back to the bridge building

So let’s take that poker example and look at it through the lens of software development.

Let us compare the engineering maturity to software development to the engineering maturity of the engineering discipline of building bridges.

I think most people would agree that bridge building is a very mature engineering discipline but many people would argue that software development is not.

How many bridges do you think have been built in the world?

Well there are about 600,000 bridges in the United States alone, so the world figure must be at least somewhere around 10 times that number perhaps 20.

How many software programs have been written?

This is a very hard number to estimate, but lets take a rough guess based on how many software developers there are in the world

If we say there are about 12 million software developers and each software developer has written approximately 3 programs, we can estimate that a large amount more programs have been written than bridges built.

My point is not to knock bridge building, we are pretty good at it as a whole, but rather to show that collectively, even though we have been building bridges for hundreds of years, we have probably devoted an equivalent amount of time to building software.

This line of thinking may lead you to argue back that software development and bridge building are very different.  Bridge building has a fixed set of requirements that are pretty close to the the same for each bridge you build, but software development is a big open void of whims and ambiguously contradictory statements.

I agree with you 100%!  And in essence that is my point.

Software development is different

And we have had enough time to realize that.  Waiting for software development to gel into some kind of engineering discipline like other engineering disciplines is like waiting for water without gelatin mix to turn into Jello. 

It’s just not going to happen!

In my mind it is clear that the argument that we haven’t given it enough time is just wishful thinking.  The nature of software development, just like online poker, leads itself to rapid evolution.

Consider what direction software development is evolving.  Is it even evolving in the direction of rigid engineering practices or is it evolving in the exact OPPOSITE direction?

Ten years ago, we tried to use UML diagrams and CASE tools to develop software.  Ten years ago waterfall was all the rage.  Ten years ago, we thought that ten years in the future we would have programs that would allow us to build software in the same way that CAD tools allow for building machine parts.

Not only did it not happen.  It went completely the other way.  Now we are all talking about Agile.  Now people don’t even remember what CASE tools are.  Now we are building software without trying to define the whole system in UML diagrams.

The fact of the matter is software systems are unruly beasts!

In my mind it comes down to one simple distinction.  Software is living, bridges aren’t.  When you are done building a bridge, you are done building the bridge. 

Sure someone, probably not you, will have to come along and do some routine maintenance on it.  Sure, some small things might change about it, but for all intents and purposes the work is done.

In most software development scenarios, this is not the case.  In most software development scenarios, releasing V1 is not even close to the end.  Sometimes V1 and V2 don’t even look that same at all.  Software development is about operating on a living breathing thing and all the while keeping it alive.

The truth is, we software developers have more in common with surgeons than with other engineers.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Find me



The opinions and content expressed here are my own and not those of my employer.