Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!xylogics!merk!alliant!linus!eachus From: eachus@linus.mitre.org (Robert I. Eachus) Newsgroups: comp.software-eng Subject: Re: recap so far Message-ID: Date: 17 Jul 90 18:09:47 GMT References: <1990Jul10.134226.22459@iti.org> <268462df> <39400111@m.cs.uiuc.edu> <31558@cup.portal.com> <27199@athertn.Atherton.COM> Sender: usenet@linus.mitre.org Organization: The Mitre Corporation, Bedford, MA Lines: 42 In-reply-to: mcgregor@hemlock.Atherton.COM's message of 17 Jul 90 00:31:42 GMT In article <27199@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: In general, management of software does want solid schedules. I find that engineers often internalize their own goals and are less flexible in changing functionality and quality than management might be. I believe that this is a social aspect. Engineers don't like to shave functionality because it is the thing that they want to do--that's why they entered the trade. Engineers don't like to shave quality because of self-integrity, they want to feel they did a good job by their own internal measures. Time frames are typically less important to software engineers, so they would feel better sliding the schedule and holding the other aspects constant... The problem with this (management) point of view is that it is often wrong in the software arena. A manager may not like the fact that Widget 4.0 still isn't shipping because of major bugs, but once you have reached that point you only have two ethical choices: Cancel the project, or keep looking for the bugs. The fact that a less ambitious revision would have shipped on time, or that the changes to add feature X probably caused the problem is now irrelevant. Taking out the mods will only make the final relase later. The analogy that I like to use is of building a house. Before the builder gets beyond the first floor it is still possible to redesign to leave the third floor out. It may not save as much money as you hoped but... However, futher down the road, there is no choice. You can't leave off the roof and still have a house to sell. Another related phenomena is that the "true" quality metrics for software are almost always Boolean. People will buy a program which gets the right answer 90% of the time, but only if they don't know what they are getting. Deliver an accounting package to a bank that almost always gets the balance correct, and the bank will be willing to discuss fixes with you--in court. -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...