billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/12/89)
From article <16193@vail.ICO.ISC.COM>, by rcd@ico.ISC.COM (Dick Dunn): > Of course good people will produce better software than bad people. [...] > But the professional won't do as good a job as if there were more > external interest in quality and less extreme time/money pressure. A long schedule can provide enough time to get a product almost perfect, but with very negative economic consequences. It is *management's* responsibility to balance quality requirements against other requirements when determining the schedule. At some point, the tradeoff must be made, and the engineers must then produce the best possible product within the specified minimum standards of quality and the cost and schedule constraints. > And what's this about advanced programming languages? Wolfe has, in other > postings, been an outspoken advocate of Ada, which is certainly *not* > advanced. Oh, then let's talk about how "advanced" C is, over in comp.lang.misc. Bill Wolfe, wtwolfe@hubcap.clemson.edu
mjl@cs.rit.edu (10/13/89)
In article <6756@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From article <16193@vail.ICO.ISC.COM>, by rcd@ico.ISC.COM (Dick Dunn): >> And what's this about advanced programming languages? Wolfe has, in other >> postings, been an outspoken advocate of Ada, which is certainly *not* >> advanced. > > Oh, then let's talk about how "advanced" C is, over in comp.lang.misc. I'm into lingua-snobbery as much as anyone else, but is this really the forum for it? And using it to willyhorton someone else's position certainly does nothing to give added credibilty to your own. So let's drop this and get back to the interesting quality issues that started this thread. Mike Lutz Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!ritcv!mjl CSNET: mjl%rit@relay.cs.net INTERNET: mjl@cs.rit.edu
rcd@ico.ISC.COM (Dick Dunn) (10/14/89)
William Thomas Wolfe writes: > ...It is > *management's* responsibility to balance quality requirements > against other requirements when determining the schedule. No. Management assists in this. Management makes the final call, but the engineers are a major part of the decision process. After all, it's an engineering exercise to determine how long it takes to do the engineering. Also, as I've pointed out (ad nauseam for other readers, I suspect), the quality characteristics I've been talking about are not readily quantifi- able, whereas the requirements I've been talking about are necessarily objective. >>In this context<< the phrase "quality requirements" is a contradiction. note in passing...I had said: > > And what's this about advanced programming languages? Wolfe has, in other > > postings, been an outspoken advocate of Ada, which is certainly *not* > > advanced. ...and Wolfe dodges it: > Oh, then let's talk about how "advanced" C is, over in comp.lang.misc. No, let's not. I won't assert that C is advanced. It's suitable. Nor did I assert that "advanced programming languages" were essential. Try to answer the question, Bill: Are you advocating use of an advanced program- ming language, or are you advocating the use of Ada? -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/15/89)
From rcd@ico.ISC.COM (Dick Dunn): >> *management's* responsibility to balance quality requirements >> against other requirements when determining the schedule. > > No. Management assists in this. Management makes the final call, but the > engineers are a major part of the decision process. After all, it's an > engineering exercise to determine how long it takes to do the engineering. Engineers repeatedly provide information as a function of the varying constraint parameters which are specified by management. Management makes the decision. Engineers then comply. Notice: *Engineering* assists. *Management* DECIDES. > note in passing...I had said: >> > And what's this about advanced programming languages? Wolfe has, in >> > other postings, been an outspoken advocate of Ada, which is certainly >> > *not* advanced. >> Oh, then let's talk about how "advanced" C is, over in comp.lang.misc. > > No, let's not. I won't assert that C is advanced. Glad to hear it. > answer the question, Bill: Are you advocating use of an advanced > programming language, or are you advocating the use of Ada? I advocated precisely what I said: "advanced programming languages", along with CASE tools and so on. YOU brought up Ada, not I. And I *will* assert that Ada is advanced, within the domain of PRODUCTION programming languages; followups to comp.lang.misc if you'd like to pursue it. Bill Wolfe, wtwolfe@hubcap.clemson.edu
rcd@ico.isc.com (Dick Dunn) (10/19/89)
Bill Wolfe said, in relation to the ongoing discussion about factoring quality into scheduling: > >> *management's* responsibility to balance quality requirements > >> against other requirements when determining the schedule. I complained about the characterizations of engineering and management roles: > > No. Management assists in this. Management makes the final call, but the > > engineers are a major part of the decision process. After all, it's an > > engineering exercise to determine how long it takes to do the engineering. There are some statements about interactions inherent in what I said. I really mean that the engineers had better *participate* in the decision process. I should have noted that, in addition to the engineering aspects of determining schedule, you have to keep the old responsibility/authority equation in balance--and it's the engineers who have the responsibility for meeting the schedule. Wolfe counters: > Engineers repeatedly provide information as a function of the varying > constraint parameters which are specified by management. Management > makes the decision. Engineers then comply. The first part works, but poorly. The problem is that (in software buzz- terms) it starts with a waterfall model, then wraps a loop around the out- side. That is, management provides constraints, engineers provide infor- mation in response--that's the waterfall pair of steps. It can take a lot of iterations to get a decent answer compared to what happens if you plunk engineers and managers down together and let them work on all of the constraints together. As for the "management decides, engineers comply" - in some sense that's what happens, but it's an incredibly poor choice of words. That is, regardless of the actions, an organization which sees its process in those terms is not healthy...it has management problems. > Notice: *Engineering* assists. *Management* DECIDES. In a wider context, this would be very unhealthy. Engineering does the work in an engineering project, and management assists the engineers in getting it done. (This comes from the observation that the end product is the result of engineering effort, not management effort.) But let's not lose sight of the fact that we're talking about setting the schedule, budget, and related constraints--this is a different context from the "real work" in the project. My contention is that even this initial work is substantially an engineering effort. If engineers are to be involved, you don't involve them as "subordinates". A perspective: When someone (even in our company) asks me who I work for, I say "Interactive Systems." If I'm then pressed for the name of a *person*, I say "Oh, you must mean `Who do I report to?'" and give them my manager's name. The distinction between "work for" and "report to" is important in what it says about structure versus control. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/22/89)
[I have removed comp.sw.components from the newsgroup list, since this thread ceased to be relevant to that newsgroup some time ago] From rcd@ico.isc.com (Dick Dunn): > Bill Wolfe said, in relation to the ongoing discussion about factoring > quality into scheduling: >> >> *management's* responsibility to balance quality requirements >> >> against other requirements when determining the schedule. > > I complained about the characterizations of engineering and management > roles: >> > No. Management assists in this. Management makes the final call, but the >> > engineers are a major part of the decision process. After all, it's an >> > engineering exercise to determine how long it takes to do the engineering. > > There are some statements about interactions inherent in what I said. I > really mean that the engineers had better *participate* in the decision > process. I should have noted that, in addition to the engineering aspects > of determining schedule, you have to keep the old responsibility/authority > equation in balance--and it's the engineers who have the responsibility for > meeting the schedule. This is exactly correct, and here we agree completely. (See below) % Wolfe counters: %> Engineers repeatedly provide information as a function of the varying %> constraint parameters which are specified by management. Management %> makes the decision. Engineers then comply. % % The first part works, but poorly. The problem is that (in software buzz- % terms) it starts with a waterfall model, then wraps a loop around the out- % side. That is, management provides constraints, engineers provide infor- % mation in response--that's the waterfall pair of steps. It can take a lot % of iterations to get a decent answer compared to what happens if you plunk % engineers and managers down together and let them work on all of the % constraints together. But these iterations can occur with everyone in the same room, working together. Management specifies some parameters, engineers provide information as to probable cost/schedule requirements, loop until the meeting is over. > As for the "management decides, engineers comply" - in some sense that's > what happens, but it's an incredibly poor choice of words. That is, > regardless of the actions, an organization which sees its process in those > terms is not healthy...it has management problems. No, it in fact shows that the organization IS healthy. 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 were responsible for setting cost and schedule constraints, they would tend to disregard economic factors and the organization would quickly find itself out of business. Projects would be technical works of genius, with complete formal specifications for each subprogram or data abstraction, 3-D images illustrating the design, etc., at a cost which would result in fatal financial illness for the company. >> Notice: *Engineering* assists. *Management* DECIDES. > > In a wider context, this would be very unhealthy. Engineering does the > work in an engineering project, and management assists the engineers in > getting it done. (This comes from the observation that the end product is > the result of engineering effort, not management effort.) The statement above relates only to the topic at hand, which is "Who is responsible for setting cost/schedule constraints?". When we move to the new and different question, "Who is responsible for delivering the product?", then in THAT context I agree completely, but this has nothing to do with the topic at hand. > But let's not lose sight of the fact that we're talking about setting the > schedule, budget, and related constraints--this is a different context > from the "real work" in the project. My contention is that even this > initial work is substantially an engineering effort. If engineers are to > be involved, you don't involve them as "subordinates". Sure you do. Who says superiors and subordinates can't participate in the same meeting? Who says superiors and subordinates can't have free and open discussions? I don't, and I hope you aren't implying this either. Bill Wolfe, wtwolfe@hubcap.clemson.edu
mjl@cs.rit.edu (10/24/89)
In article <6847@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From rcd@ico.isc.com (Dick Dunn): >> As for the "management decides, engineers comply" - in some sense that's >> what happens, but it's an incredibly poor choice of words. That is, >> regardless of the actions, an organization which sees its process in those >> terms is not healthy...it has management problems. > > No, it in fact shows that the organization IS healthy. 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 were responsible for setting cost and schedule constraints, > they would tend to disregard economic factors and the organization would > quickly find itself out of business. Projects would be technical works > of genius, with complete formal specifications for each subprogram or > data abstraction, 3-D images illustrating the design, etc., at a cost > which would result in fatal financial illness for the company. I can't let this one pass, if for no reason than to defend the honor of engineers. I don't think we can (or should) use the Nuremburg defense "I was only doing what I was told." 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! Like most others who've been in this business for any time, I've seen examples of what Bill is talking about. Still, this was usually due less to engineers violating budget and time constraints than it was a lack of management direction -- by which I mean setting clear goals for what was to be done. People fritter their time away when they don't have a clear vision of where they're going. But once goals are established, the engineers should have significant if not primary control over how to get there. 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. I have no problem with management proposing budget and schedule constraints, but the engineering staff is best qualified to determine whether there is a feasible solution within these constraints. And "feasiblity" in this case includes adequate time to produce a quality design that has a high probability of successful evolution over the lifetime of the product. Bill's snide remarks notwithstanding, sometimes this will mean creating a formal spec. and a variety of related models to ensure a well-engineered piece of software. In my experience, managers consistently underestimate software product lifetime, possibly because they base their estimates on hardware development models. When the hardware subsystems are no longer up to snuff, they are are often redesigned *from scratch* using the latest technology. However, most organizations work under the implicit assumption that software need *never* be redesigned from scratch -- it can always be modified to meet new requirements. I have in mind several projects I've been involved with over the past couple of years, where the hardware base evolved in stages from first generation mini's (like PDP8's and Nova 1200's) to 68K's and 80xxx's. While the current processor boards and attendant interfaces look nothing like their ancestors, the current software system architectures still reflect the original designs (or lack thereof) from the early 70's. For those interested in the issues surrounding long-term product evolution, I strongly recommend Belady & Lehman's book "Program Evolution: Processes of Software Change" (Academic Press, 1985, ISBN 0-12-442441-4). The typography is awful, and I think the proof reading phase was skipped, but the ideas and insights are well worth the time it takes to ferret them out. Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!ritcv!mjl CSNET: mjl%rit@relay.cs.net INTERNET: mjl@cs.rit.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/30/89)
[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