shap@bunker.UUCP (Joseph D. Shapiro) (03/10/88)
In article <2541@Shasta.STANFORD.EDU> neff@Shasta.UUCP (Randall Neff) writes: > >State-of-the-practice in Hardware: >...the first parts produced USUALLY work correctly... > >State-of-the-practice in Software: >... [usually doesnt]... As one who advocates carefully planned and controlled software projects, I offer the following observations on why some projects are run on a crash basis, and why poor or unstable software is shipped. 1) Software follows hardware. People will not push as hard for new hardware if there is no software to drive it, but once the hardware is ready, WE NEED THAT SOFTWARE NOW. A related issue is that in a hardware/software combined project, the end date will often be fixed, and if the hardware portion runs so late as to impact software testing, there will be greater time pressure on the software team. 2) Companies know the real cost of shipping defective hardware. You gotta recall the equipment, extract the offending piece, replace it, or cut/add traces, etc. There are real identifyable costs involved in shipping, reworking, spare parts, etc. For software, the effects SEEM less costly. Mail another diskette or tape. 3) There is a perception that everybody ships software before its time. A company has to decide whether to also ship prematurely, or take the time to do it right and suffer the real/imagined opportunity cost of being the last one to announce/deliver the product. The people who shipped the shoddy software months ago may have had to ship several updates, BUT THEY GOT THE SALE. My own feelings are that the carefully planned and controlled project should produce quality software just as quickly as a rush job could produce shoddy software. The problem may be that upper management may see a schedule that includes X months for planning, designing, and specifications, X months for CODING, and X months for integration, testing, etc, and wonder why it should take 3X months to finish the project when all the "real work" only takes X. DISCLAIMER: ANYTHING ATTRIBUTED TO 'MANAGEMENT' OR 'COMPANY' IN THIS ARTICLE DOES NOT NECESSARILY REFLECT THE OPINION OF THE MANAGEMENT OF BUNKER RAMO OR OLIVETTI. In fact I know that my management takes software quality as seriously as I do. My observations here are based on broad experience of over ten years. -- -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Joe Shapiro "My other car is a turbo... Bunker Ramo Olivetti too." {decvax,yale,philabs,oliveb}!bunker!shap