From: killops@ssd.intel.com (Scott Killops)
Newsgroups: comp.software-eng
Subject: Re: Goal of Software Engineering (Was: Do Software Engineers Actualy do so
Keywords: Money Predictability Goal
Date: 15 Oct 92 17:01:12 GMT
Followup-To: comp.software-eng
Organization: Supercomputer Systems Divison, Intel Corp.

In article <1992Oct15.122003.24448@afit.af.mil>, jcardow@afit.af.mil (James E. Cardow) writes:
|> killops@ssd.intel.com (Scott Killops) writes:
|> 
|> >In article <1992Oct14.210241.3504@afit.af.mil>, jcardow@afit.af.mil (James E. Cardow) writes:
|> >|> 
|> >|> But let me ask a really off the wall question (academics this one will
|> >|> hurt), why isn't the goal to make money for us as well?  
|> 
|> >I answered before that the goal of *software engineering* is predictability.
|> >Another way of saying this is that we use software engineering in order to
|> >reduce the risk associated with trying to make money through producing and
|> >selling software.  (In critical applications, I would say that we employ
|> >software engineering in order to reduce the risk of a catastrophic failure
|> >of the deployed software.)
|> 
|> I'm not so sure.  I was following the same line of reasoning originally.
|> That is, as a purist, the goal of *software engineering* can't be to
|> make money.  But what is the result of predictability?  Being able to
|> adjust to levels of uncertainty to maintain balance?

Bring it down to the personal level.  Make it real.  An organization predicts
that it can deliver a product with a set of features by a certain date.  It
often books business or signs contracts based on this prediction well in
advance of that date.  If it fails to deliver, at least the larger of the
customers will be making loud angry noises at high level managers in the
organization.  This may be because some of the managers in the customer
organization have made "career betting" decisions to select your product
over a competitor's and the customer is well underway in a multi-million
dollar project of which your product is only a part.  When million+ dollar
customers make angry noises at high level managers, they turn up the heat
on middle level managers who, in turn, turn up the heat on individual
contributors.  In poorer organizations, this may take the form of threats
(real or implied) or admonitions to simply work harder.  In better organi-
sations, it may take the form of increasing the level of monitoring and
control, resorting to contingency plans, creating "tiger teams", etc.
Either way, it's no fun.  If you live through it, you don't want to do
it that way again.  The search for better ways is the attempt to define
software engineering.

At a truly personal level, if I can't make and keep commitments with a
reasonable degree of predictability within my organization, I will hear
about it from my manager.  It doesn't matter what the literature says
about the reliability of formal or informal cost estimation models.  I've
got to do the best I can.  Because if I and the others on the team do not,
the project will be late and real customers will make noise.  I don't
like to hear bad things from my manager.  And I don't like to work 16
hour days to make up for poor estimates in order to meet my commitments.
So I look for better estimating techniques.
 
|> As for the high tech layoffs, that presents a problem.  The layoffs do
|> not appear to be the result of increased productivity.  Nor do they appear
|> to be the result in a down turn in the demand.

The layoffs I've lived through have been pretty straight forward.  In two
companies I have worked for and several others that I have observed in this
area, layoffs had a direct connection to both money and software engineering.
The company was over a year late in delivering a major new high-end product,
sales began to fall off, the company started losing money, and people got
layed off as the company struggled to control the flow of red ink.

|> Do ethics and safety still fall under the umbrella of *making money*?
|> Now as easy to fit into the formula, but I have to reflect back on the
|> auto industry.  They are driven by sales and lawsuits to make safer
|> cars.  Both affect the bottom line of money.

Sure.  Of course they do.  Looking for a single goal for an organization
is an oversimplification.  Money is an important goal because unless you
make money, your organization does not survive to pursue other goals.  But
if you don't satisfy your customers, you won't continue to make money.
And if you don't control costs, you won't keep up with competition. And
if your product is unsafe, you risk expensive lawsuits or shutdown of
your business by regulatory agencies (apart from the overriding moral
obligation for safety of others).

I think the "What is the GOAL?" exercise is fun and useful.  It helps me
clarify my thinking and make useful distinctions.  But in the end, there
isn't one goal because software organizations are made of complex people
trying to do complicated things.

On a related note, I really like Basili's (et al) Goal/Question/Metric
paradigm for choosing software metrics to use within an organization.
I think that the explicit consideration of organizational goals in the
metrics discussion helps select a truly useful set of measurements.  I
noticed that both Grady and Fenton mentioned GQM briefly in their
recent software metrics books, so others must find it useful (or at
least appealing) as well.

Chow, Scott
killops@ssd.intel.com
Newsgroups: comp.software.licensing