Maybe Software Development IS Like Building a House
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.