Your Software is not a House

June 15, 2010 CollabNet VersionOne

I’ve said it myself before – this software needs to be designed  properly; You know, foundation of a house, and such.  Once the design is  solid, oh just trust me, we will create some software real fast.  And  then we went off to ponder and pontificate, and create documents showing  how elegant this solution would be.  We used and diagrammed all of the  proper patterns, creating interfaces and abstractions along the way.

We  wrote code; tons of code.  We deviated as we learned more of the  system, as time became tighter, and so on.  Once the project was  released, ‘Someone should really update that design document’…and no  one does.

Its common, it happens.  I’ve done it.  But this isn’t  about the benefits of emergent design, lets look at the common idiom of  our software being a house.

Would  you want the real version of the house based on the software you  build?  Would you want your contractor to agree to a set of prints up  front, but once you move in realize that the only way to turn on the  lights was to flush the toilet?  How about that study you wanted?  Would  you be happy if your carpenter decided that you, ‘the user’, wouldn’t  need a study?  Would you feel better if afterwards, the architect came  back and updated your blueprints?

4,192,876,492 – that is my  estimate of the number of unneeded interfaces in code out in the wild  right now.  Would you want that many light switches in your house, you  know, in case you wanted to switch something else on besides the ceiling  light?

Houses can have blueprints because they are based upon  static principles with high commit costs.  A foundation is made of  concrete.  You can change it but it will cost substantially and can  create structural risk.  Software is malleable and code is not  concrete.  We should be exploiting that benefit instead of trying to  move towards a less flexible model.

Lets take this a step  further.  Houses are built upon civil engineering principles – stress  loads of materials, heat dispersion, pressurized values of systems.  For  example, the beams supporting your walls are probably slightly over 14  inches apart.   That is not because that was a good number to go with.   That is because we know, through testing, that the stress load we can  expect a wall 2 by 4 to support is actually 24 inches on center but  because of the varying in woods (drying, species), most carpenters build  at 16 inches on center.

What would be similar in concept to  this?  Programming languages, platforms, maybe containers or  software development frameworks.  We know how languages function in certain applications and  situations; what platforms work best for certain targets; what  containers will provide for us.  Even these can be changed – swapping  containers shouldn’t be painful.  These items are addressable upfront.

Finally, have you ever heard of a civil engineer say ‘concrete isn’t  good enough for this common residential house, I am going to invent  something new.’?  You don’t, it would be ridiculous, overly costly, and  people could die.  But in software, too often we design and say  something similarly absurd. ‘We need a custom web server, Apache  wouldn’t scale for our special problem’.  That statement is as  ridiculous as trying to make your own concrete.

Read more by Joel Tosi @

The post Your Software is not a House appeared first on VersionOne Blog.

Previous Article
How many printers does it take to build your application?
How many printers does it take to build your application?

Its a little known fact that Google was built by 3 staplers, a set of  paperclips, and a couple of 2 by 4s....

Next Article
Change Without Motivation
Change Without Motivation

One of the most potentially dangerous states for a company to be in is   where it is  successful in spite o...