The construction analogy — estimation
What got me thinking about the construction analogy with software development was a recent conversation I had with a design/build contracting company. We’re in the market for a new house. We sketched our design (which we’ve worked on for quite some time) and wrote up a list of general assumptions about level of quality and some details that we wanted. We sent this out as a letter to a bunch of builders.
That sounds somewhat like your typical business requirements document, doesn’t it? It’s too detailed (specifying implementation details) while simultaneously failing to mention important points. But it’s a starting point for conversations.
A small number of builders responded to our Request For Proposal. The first one to come by and talk with us brought a very nice portfolio of photos of houses his company had built. He explained how his company ran projects and told us he could give us a fixed-price quote once the design was complete. Oh, and we would pay for the design effort by the hour.
This sounded a little waterfallish to me, but then he explained that, as the design progressed, we could make better and better estimates of the cost and that we could call a halt at any point. Ok, that’s a little better. I understand about refining the estimates. Of course, abandoning the project is really not acceptable to us. We still need a house, and we’re willing to make adjustments to get a house that we can (almost) afford.
The kicker came when I asked for a ball-park estimate. There are times when I’ve felt very uncomfortable giving an estimate on too-little data because people are wont to treat them as promises or commitments. Knowing this, I gave him assurances that we just needed a figure for planning purposes. After all, the bank wasn’t going to give us a blank check. Just an estimate to the nearest $50K dollars would do.
The response was disheartening. He couldn’t tell us whether our house, as described, was closer to a $200K house or a $400K house. It seemed to be a small thing to him. After all, we only had to pay their designers $85/hour for a “Preliminary Design/Feasibility Study [costing] up to a maximum of 3% of estimated project cost.” Ignoring the fact that the cost of the study was estimated as a percentage of the total cost that the study was estimating, this proposal was totally unacceptable to us. All we had been given for making a decision on whether or not to choose this builder was some glossy brochures and a talk about how wonderful they were.
Unfortunately, I fear that some software development teams approach estimation in much the same fashion. Perhaps this has engendered some of the much-discussed “agile backlash.”
While it is true that the more you work on the project, the better (if you approach it well) you can make your estimate. And while it is true that there’s an unfortunate human tendency (often magnified by an unequal power relationship) to hear an estimate and take it as a commitment. It is also true that the person (or company) commissioning the work needs some sort of estimate to make rational choices about how to proceed.
Ken Auer has a wonder description of using a simplified Planning Game to provide such a description in Extreme Programming Applied: Playing to Win (see pp. 112-114). This sidebar, alone, is almost worth the cost of the book.