Xref: utzoo comp.sw.components:370 comp.software-eng:2236
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Software quality
Message-ID: <6847@hubcap.clemson.edu>
Date: 21 Oct 89 20:17:55 GMT
References: <1989Oct19.042903.7809@ico.isc.com>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 87


 [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