Xref: utzoo comp.sw.components:299 comp.software-eng:2090 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.sw.components,comp.software-eng Subject: Schedule and budget are secondary Summary: avoiding games Message-ID: <16168@vail.ICO.ISC.COM> Date: 6 Oct 89 06:24:53 GMT References: <6630@hubcap.clemson.edu> Organization: Interactive Systems Corp, Boulder, CO Lines: 61 billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes, among other things, that: > ...But engineers don't play; this is left > for hackers. We're here to engineer products on time, under budget, > and with as much quality as we can get within those two constraints. Actually, engineers *do* play; the ones who don't seem to be playing are playing at being engineers. But that's another posting. Here, I want to assert that the "on time, under budget" phrase is a red herring. (BTW, why not "ahead of time, on budget" or even getting both right and being "on time, on budget"? But that's another digression...) It's particularly sad to see "quality" a poor third to the other two. You can make any feasible software project come in on time by setting a long enough schedule, and of course you can bring it in under budget if you set aside enough money. That's why we've got a red herring--the numbers can be tweaked. Moreover, this is not just an idle observation... There are lots of "methodology mavens" on the loose these days. They'll sell you or teach you a way to improve the predictability of your software projects. An unfortunately large proportion of them do it by adding make- work to projects, in a particular way: They front-end load the project with paperwork, rituals, meetings, millstones, etc. What does this do? - It increases the total time/budget for the project, providing a way to hide needed time/money. If things start to get tight, the ritual gets short shrift; the effort gets shifted to real work. You get a safety buffer you don't have to justify. - It lets you hire (or assign) the people you're going to need in the later implementation phase early on...and it gives them some- thing to do (push paper) without getting in the way too much. (After this, they'll be GLAD to get to work!) This allows lazy management to deal with a flat staffing through the project. - It adds to the total time/money for the project, so that any error in estimation induced by true risk is reduced in apparent magnitude by the slopfactor. The next point may come as a radical surprise (or affront) to the academi- cians (and Adacademicians especially), but: It's not necessarily best to produce a schedule which you know you can meet at a very high confidence level! Sure, if you're aiming for a hard deadline or bidding a contract fixed-price, you need to hit pretty high confidence. But in many cases it makes more sense to set the schedule at the most probable completion time. That's the most useful for planning. For example, in the commercial world, aiming for a 90% confidence-of-completion time on a schedule might cause you to decide you can't meet the market window for a product--when in fact a more realistic confidence level in scheduling will tell you it's worth the chance. In any event, a single "schedule end date" or "cost" for a software project is carelessly simplistic; it's as bad as rating processor performance on a single number. You need to associate confidence levels with the values. But overall, Wolfe has it backward. You need to produce quality software that does what it's supposed to do. Then you need to do it predictably. But if the software doesn't work, it doesn't matter how quickly or cheaply it was done. -- +---------+ Dick Dunn rcd@ico.isc.com ico!rcd (303)449-2870 | In this | 4th annual MadHatterDay [10/6/89]: | style | A Thousand Points of Madness |__10/6___|