Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Jun 15, 2010 — Enterprise Agile Planning expert

Your Software is not a House

Enterprise Agile Planning


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.


More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us