Home > Agile, Development, Rants, Software > Maybe Software Development IS Like Building a House

Maybe Software Development IS Like Building a House

February 5th, 2008 Leave a comment Go to comments

A few years back, my wife and I built a house. OK, so *we* didn’t actually swing a hammer; if you’ve ever seen me attempt a project around the casa, you know hiring the project out was the sanest course of action. This was my second go round with home construction, a process that many say they’d never repeat. But hey, I’m a glutton for punishment so in we plunged! I’d mostly walled off the entire experience in that place we put painful events like child birth and two-a-day practices, but last week one of my projects got me thinking that maybe, just maybe, there’s a comparison to me be made between house construction and building software.

Before I get started, I have to consider whether I’m on shaky ground here – many people have written pieces questioning the whole construction analogy. For starters, my friends Neal Ford and Glen Vanderburg have their takes with building bridges without engineering and bridges and software. Jack W. Reeves’ classic What Is Software Design? is a must read and Reg Braithwaite has a great post about what he admires about engineers and doctors which has this money quote:

Try this: Employ an Engineer. Ask her to slap together a bridge. The answer will be no. You cannot badger her with talk of how since You Hold The Gold, You Make The Rules. You cannot cajole her with talk of how the department needs to make its numbers, and that means getting construction done by the end of the quarter.

Considering the shared experience behind that impressive collection of wise words, I’m questioning my sanity to even think a construction analogy might fit software. But, even though I’m conflicted about the whole thing, I’m still going to share. Heck, maybe I’ll learn something in the process.

When we built our house, we spent several weeks looking at model houses, poring over floor plans, looking at carpet samples – all sorts of fun stuff. Now, with the last “home project,” during the requirements gathering phase we were just focused on the big issues: do you want a built in here? Would you like a fireplace? How about a skylight here? You know, the stuff you’ve got to get right before the foundation is set and the walls are up. At various stages, I’d get a call from the project manager (yep, that was his title, I’m feeling more confident already!) and he’d setup a time for me to come out to the site and work with one of the trades on issues like outlet placement. With my sample size of one, I expected a similar (iterative) process this go round – alas I was wrong.

You see, this builder had a different approach. They believed heavily in making all (and I mean ALL) the decisions up front (can you say BDUF?) Being a software geek, I think I do a pretty good job of thinking abstractly but needless to say, it can be quite a challenge to figure out where you want your phone jacks when all you have to go on is a 2D model of your future dwelling. I pushed back on the builder and was told they did this for a reason – they felt that if everything was on the plan, I could go on (as they put it) a four month vacation and come back to a completed house *exactly* as I intended it to be.

As much as I wanted to believe the people I was about to give a very large check to, I wasn’t convinced and as you might expect, my wife and I were on site pretty much every other day keeping track of what was going on. It was a good thing we were vigilant customers constantly running our acceptance tests. Nearly every visit revealed something that needed to be fixed, a story to be added to the backlog (or punch list in this case.) Some things were minor – a switch not controlling the proper light or a misunderstanding about what the plumbing code would allow. But others were, well, of the show stopper category. For example, despite a very clear floor plan showing where the washer and dryer were to be, the plumber decided he’d just put the washer where it was in every other house. Thank goodness we caught it early but this whole “we get it on the plan thing” certainly didn’t work in practice.

So what the heck does this have to do with software? Well, one of my projects has a customer group that thinks like my builder – they want to give us all the requirements, we give them an estimate, then they don’t talk to us until the project goes live. Obviously, this doesn’t work too well. I’m not sure why people ever thought this approach worked, heck, if we can’t get it right with houses (something we’ve been building, oh, forever) how can we possibly get close with a discipline as new as software? No, the answer is found in an agile approach where we work closely with our customers. Does that mean we need to see them for eight hours a day everyday? I sure hope not, but if they aren’t willing to commit some time to the project, how important could it actually be?

Needless to say, we’re trying to get the customers to think different, to embrace a more collaborative approach and I hope we succeed. Otherwise, I have a pretty good idea what will happen after that four month vacation.

Categories: Agile, Development, Rants, Software Tags:
  1. Pete Ruth
    February 6th, 2008 at 00:22 | #1

    Great post. I started building software like contractors build homes in 1972, using a general-purpose system framework and customizable reusable components and a collaborative process very similar to today’s agile methods and incremental/iterational processes. That approach evolved into a generative component-based development process in about 1978, and I’ve been using it ever since. This combination of approaches affords a great deal of flexibility in terms the development process, and estimating the associated project cost and schedule. This enables working software to be built and reviewed in near real-time. The basic premise is to do the most challenging or important stuff first, transfer the most business value to the users as quickly as possible and identify problems as early as possible to mimimize costs. The generative part produces 75-90% of the total system code automatically; the rest is related to the code that differentiates one application from another, or modifications to the existing components to satisfy unique module requirements. The key to this approach is the degree of “granularity” of the component templates: too fine, and keeping track of everything becomes increasingly difficult as the application grows, too coarse and the number of modifications to generated components increases. Another benefit of the generative process is that multiple approaches to building the application may be explored in parallel with little risk. Modularization at this level enables specific functionality to be “localized”, yielding substantial post-deployment benefits, like improved sustainabilily and extendability. (Some of the systems built this way have outlasted the platforms on which they were implemented several times over). These factors may provide extremely good TCO figures. The bottom line is this: being able to create bullet-proof custom applications in a fraction of the time and cost of other methods means that that risks typically associated with software development are substantially reduced, and payback comes much earlier.

    Thanks again for an interesting post.

  2. February 6th, 2008 at 17:18 | #2

    Don’t doubt yourself. I think the construction analogy is still appropriate and sometimes even helpful. It’s the engineering analogy that has always been misplaced and troublesome, in my opinion. The example you give is, I believe, the best one for most software development projects. The building of a custom house (or other building) is an excellent analogy to a custom software project. There are engineering principles involved, but you wouldn’t refer to your average home builder as an “engineer”. There are pre-built components that can be used. There is an overall architecture. There is a more detailed design. The construction process uses engineering principles and standardized tools to implement that detailed design while staying within the boundaries set out by the architecture. Most of the work that is done while building a home is the same as the work that was done for the last one, but the outcome is unique and the problems that arise are also.

    Then there is your point. Home construction, just like software, can be done following an agile or waterfall methodology. Obviously, home construction can’t be quite as agile as software. As Neal points out the manufacturing costs of software are much lower which means the cost of change is lower. But the principles are still the same. The cost of change increases the later the change is made. How much more would it have cost if you didn’t catch that plumber in time? Rapid feedback and flexibility are just as valuable in home construction as they are in software development.

    So, I agree with you 100% but I am miffed at you for posting this. Just yesterday I was thinking of finally getting into this blogging thing (realizing that in our industry if you don’t blog you don’t exist) and I was going to write about this in my very first post. Now I’m going to have to wait until I get another interesting thought. Who knows how long that will be?

    Anyhow, great post. Have a good time in Boston.


  3. February 10th, 2008 at 15:00 | #3


    Thanks for the insightful comment – you’ve hit on some key issues there. I’ve seen so many projects fail because they didn’t deliver that business value early…they just spun on and on. Your point about risks resonates as well – it amazes me that customers and managers continue to cling to what is arguably a much riskier approach to developing software (and one that has a very poor track record of success I might add.) BTW, are you, by chance, the Pete named in Imaginate?

  4. February 10th, 2008 at 15:21 | #4


    Sorry I stole your topic ;) it wasn’t deliberate! I sure hope you jump into the fray – the blogosphere can sure use more reasoned voices. I think those that abuse the construction analogy underestimate just how much “guess work” there really is in building a house (or any custom structure.) As you state, there’s the overall architecture but when push comes to shove, the craftsmen have to make a lot of decisions…just like those of us building software. Gee, there’s more to this than I thought!

    Boston was great – a short trip with a VERY early wakeup call but I had a blast. Thanks for your comments!

  5. October 10th, 2011 at 14:01 | #5

    I stumbled upon your weblog on google and look some of the early discussions. Keep up fantastic perform. Seeking forward to studying more within you at a later time!…

  6. December 21st, 2011 at 19:46 | #6
  7. February 10th, 2017 at 05:03 | #7

    This is so popular game.

  1. February 6th, 2008 at 01:22 | #1
  2. February 8th, 2008 at 14:04 | #2
  3. February 10th, 2008 at 15:28 | #3
  4. July 2nd, 2008 at 20:51 | #4
  5. December 20th, 2012 at 19:33 | #5