Your Software is not a House

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 @ http://communalosmosis.com/

This entry was posted in Agile Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>