The Construction Analogy

This is a common way for people with little experience to analyze or (gasp) explain the process of creating software. The problem is, building a house and creating a custom software application have little in common. Not nothing, but very, very little.

Here is a classic situation. Joe the sales guy is explaining his company's software development process to a potential client. The client questions why a large requirements document is necessary. Joe gets animated (apparently, he's really experienced) and says, "Well, it's like you're building a house. You need a blueprint. Your builder needs to know how many rooms, where the plumbing, electrical and HVAC goes, where the bathrooms are... heck, it's not like you can get half way through building a 2500 square foot colonial and then decide that you really need a 4000 square foot ranch."

Actually, the "2500 square foot colonial --> 4000 square foot ranch" is exactly what you frequently do on a software project. In fact, if you can't do that for your clients you're likely locked into a very poor development process. But there is much more to why this analogy has little merit.

How about some more Joe-isms about software development:

• "You can't just rip apart the foundation while you're finishing the attic." Yes, you can.
• "You can't finish a brick house and then decide the windows are too narrow and change them." Yes, you can.
• "It would be like taking a single family house and turning it into an apartment." What's the big deal about that?

Construction workers are not typing code. They can't copy and paste. They have to deal with gravity, building codes, materials suppliers, the weather. We don't have these issues in Windows, .Net, or the web.

When you build a house, you have to follow the waterfall methodology. That is, you need a plan that is complete, then you begin construction, starting with excavating a hole in the ground for the foundation, then you pour the concrete, then you frame the ground floor, then you frame the walls, then the roof, etc. After that, the building inspector can look things over and approve it. Only then can the electrician come in and run the wiring. Et cetera.

The waterfall process, which is so core to the construction industry, is a very poor approach for most (but not all) software development. Why is it poor? Because it locks you into a fixed course in a process that requires constant discovery, revision and reaction to changing business requirements, stakeholder feedback, and competitive pressures. Your building just needs to get finished so the family can move in, or so the software company can set up its servers and start writing some code! Waterfall may be a good process (I'm not 100% convinced, but it may be) if the software you are creating is similar to many other projects you've done. Of course, if that's the case, you might be better off just finishing it one last time, boxing it up, and selling it at CompUSA for $49.99. You don't need a process for that ever again.

In what I feel is a more sinister result of this construction analogy, we have people known as project managers who have been trained to bless this waterfall approach to software development. I recently had a conversation on a flight to visit a client with a woman who works for EDS. She was a project manager and was complaining about how her clients are constantly changing their minds about software that was "under construction." I tried to think of a project I have worked on where that did not happen. I can't recall a single project.

The PMI (and I am not an expert at their certification but have worked with people who are PMI certified) seems to endorse these staid methodologies. I may be very wrong about their focus, but when I read an overview of the PMP credential, I see that it includes the following: "initiating the project, planning the project, executing the project, monitoring and controlling the project, closing the project..." This smacks of a construction project in my book, not software development. The few people I have experience working with who are PMP certified seem to endorse this. Again, in some projects this may be a valid approach (and again, I'm not convinced it is, but it could be sometimes).

So does all this mean I feel that planning and project management and some structure is bad for software development? No. You need to plan, manage, and rely on some structure. But it is different for a construction project than it is for a software project. And thankfully, the software industry is responding very well. The problems of estimating, collaborating, managing and creating software have been studied by a lot of very smart people. Martin Fowler, Scott Ambler, Alistair Cockburn, Grady Booch, Kent Beck, Ken Schwaber, and heck, a lot of mere mortals, even me.

The construction analogy is way off for most software projects. Sometimes it is good for explaining to a client the challenges in estimating costs, for example, or to illustrate the complexity (at a very high level) of developing software. I think any other use of this analogy stretches its validity, and I think people have to stop raising it as justification for almost everything.

The construction analogy is not valid. In fact, software development is mostly a unique activity.