Xref: utzoo comp.software-eng:2268 comp.sw.components:385 Path: utzoo!attcan!uunet!wuarchive!mailrus!uflorida!gatech!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: comp.software-eng,comp.sw.components Subject: Re: Software quality Message-ID: <6897@hubcap.clemson.edu> Date: 29 Oct 89 18:53:08 GMT References: <1357@cs.rit.edu> Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu Lines: 68 Followups-To: comp.software-eng [Somehow, comp.software-eng got dropped from the newsgroup list in favor of comp.sw.components; I have added it back, since this thread *really* belongs in comp.software-eng rather than comp.sw.components!] From mjl@cs.rit.edu: >> [I wrote:] Engineers >> are not, and should not be in the business of trying to be, responsible >> for setting cost and schedule constraints. They ARE responsible for >> providing as much information as possible to management as it weighs >> technical and economic factors in the process of making the decision. > > If engineers realize that managment's requests/requirements/demands > are impossible to achieve, they have the right -- the obligation -- > to object, if for no other reason than to protect the shareholder's > interests against the unrealizable plans of management! [...] Most > fiascos I've seen have resulted from management inability or > unwillingness to face facts: what the project would cost and > how long it would take. Perhaps so, but I think it is a gross misinterpretation of my position to imply that I am suggesting that engineers should not make their objections known to management. This comes under the part about "providing as much information as possible..."!! Now assume that engineering has made its views known, and that management sticks with its decision. We must consider: 1) The engineers could be wrong. Management could be taking a calculated risk that research efforts taking place in another part of the company will provide the tools needed to bridge the gap, management could be dealing with a group of engineers which largely is fresh out of college, etc.; we cannot automatically discount the possibility that the management has access to better information. Indeed, it is a primary function of management to see to it that information is considered on a larger scale than simply that information which is visible to a single department. 2) What if management *is* wrong? Amdahl, I believe, gambled that it would be possible to perform wafer-scale integration and lost; but that does not mean that such projects should have been met with engineer-level revolution. Management may well have more in mind than simply achieving the direct objectives of the project. 3) Engineers are free to resign if they believe the project and/or the company will go down the tubes. Many good products have resulted from engineers deciding to form their own company, and I believe that engineers should be perfectly free to take this route if they deem it appropriate. Alternatively, they can buy 51% of the company's stock and then fire management. Or they can try to convince upper management or the stockholders that management is in need of closer supervision. But it is NOT within their realm of options to usurp management's rights and responsibilities. > sometimes [good design] will mean creating a formal spec. and a > variety of related models to ensure a well-engineered piece of software. The citation did NOT imply that formal specs are not valuable, only that a formal specification of EVERYTHING is not presently applicable to many situations due to the great cost of specifying things with that level of detail. Clearly, there are some situations in which the currently extremely high costs are justified. Bill Wolfe, wtwolfe@hubcap.clemson.edu