Xref: utzoo comp.sw.components:362 comp.software-eng:2212
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!ico!vail!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Software quality
Summary: bad words about management
Message-ID: <1989Oct19.042903.7809@ico.isc.com>
Date: 19 Oct 89 04:29:03 GMT
References: <16209@vail.ICO.ISC.COM> <6781@hubcap.clemson.edu>
Organization: Interactive Systems Corporation
Lines: 57

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.