From: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Teknekron Communications Inc.
Date: Fri, 16 Oct 1992 19:34:13 GMT

In article <1992Oct15.010329.10338@news.arc.nasa.gov> lamaster@george.arc.nasa.gov (Hugh LaMaster -- RCS) writes:
>In article <1992Oct13.060652.10180@tcsi.com>, Michael Turner (miket@tcs.com) writes:
>|> In article <1992Oct10.040112.16113@nstn.ns.ca> bushell@fox.nstn.ns.ca (Tom Bushell) writes:
>|> >
>|> >
>|> >In the article that started this whole thread, Ken Magel asks:
>|> >
>|> >>Do Software Engineers Actually Do So Badly?
>|> >>
>|> >In Brad Cox's book: "Object Oriented Programming" from 1986, he
>|> >quotes an inquiry carried through by the U.S. Government
>|> >Accounting
>|> >Office in 1979, in which a breakdown of software costs versus
>|> >actual
>|> >results is performed (FGMSD-80-4). The results at that time were:
>|> >
>|> >Software paid for but not delivered: 47%
>|> >Software delivered but not used:     29%
>|> >Software abandoned or reworked:      19%
>|> >Software used after change:           3%
>|> >Software used as delivered:           2%
>|> >
>|>
>|> Granted, this is *government* work, but it compels the question: why
>|> is a failure rate like this tolerated?  Clearly, it must be.  I wouldn't
>|> be surprised if these figures reflect a waste of taxpayer's money
>|> that outstrips all that was lost in the S&L fiasco.  Why is there no
>|> congressional inquiry going on?
> 
>Clearly someone must have been interested in understanding it, or there
>would have been no such major study, if indeed that is what took place.

It was not a major study.  If I remember right, it only looked at about
10 projects.  Also, just because *someone* was interested in it doesn't
mean that very many other people were.  A study showing results like
this should have provoked more controversy and more studies, to verify
the accuracy of these estimates.  I don't know of any other similar
studies--and few programmers I know can name even ONE such study!
I don't think it's a very popular subject--possibly, as I suggest,
because it's so politically sensitive.

>The thing which one must keep in mind with software is that the
>*design* component of project costs is very high (something also true of
>a number of aerospace systems) compared to, for example, Civil Engineering
>projects.  And therefore costs are very variable.  This seems to bother a
>lot of people, who still think we are in a "crisis" after over 20 years  ;-)

I think software costs are variable in part because design costs (even in
an ideal world) are quite variable, but are even more variable because
customers aren't paying out an even *larger* portion of the total cost
for the design phase.  The question in my mind is, Why won't they?
My answer is: it doesn't matter very much to the people paying for it,
because your average failed information system doesn't leave crispy
corpses in the snow.  It would never matter as much as a good passenger
plane design, even if it ended up costing twice as much.  Success and
failure are just too nebulous in software.

>P.S. The S&L bailout is much more expensive than you think!

Maybe the "software crisis" is much more expensive that *you* think!
Again, if nobody's aware of the true extent of the problem, how can
anybody say how much it has cost?  If it's expensive, and goes
unmonitored, it's safe to say that it's dangerously out of control.
Could it come to as much as $4000 per taxpayer?  Isn't that in the
ballpark for the S&L crisis?

>|> The fact is, the payback on investment in software projects is often
>|> not carefully measured (or measured at all).  In large organizations
>|> (governmental and corporate) all over the world, powerful people who
>|> don't have much of a clue about computers are charged with the
>|> responsibility of computerizing one thing or another.
> 
>Maybe so, but U.S. service industries are the most computerized in the
>world, and, according to a report I read about last night, the most
>productive.  It is hard to say how much computer-based systems have
>played in this, because they are so pervasive.

*Spending* on systems as part of an agressive pursuit of competitive
advantage by ALL of the best players tells you nothing.  If everybody in
an olympic track event wore 5 lbs of weights while racing, you'd
be hard pressed to determine how much this handicap was "helping"
them.  The fact that they would all still probably run faster than
your average high-school track team would also tell you nothing.

If the *most* computerized service industries in some given national
market were the also most competitive, you'd have a case.  But figures
I've read seem to track a slight *negative* correlation between degree of
computerization and competitiveness, where there's any correlation
at all.  [_The Business Case for Computers_, Paul Strassman, 1990]

>                            As DeMarco says, you can't control what you
>|> can't measure, and you sure can't measure what people aren't telling
>|> you about.
> 
>I think a lot of software project costs *are* measured.  The problem is,
>it is hard to predict software costs *in advance*.   

No, the real problem is: how do you measure the impact of the system
on the bottom line?  You can't even say for sure if the cost of anything
is out of line unless you have measured the payback.  If it was simply
a matter of who can develop systems more cheaply and predictably,
competition would be meaningful because it would have an obvious measure:
pure cost.  But since *benefit* is so hard to ascertain, you often can't
get a cost/benefit ratio comparison on different designs.  If you can't
tell a good system from a bad one on the balance sheet, you get into
the murky realm of politics very quickly.  In this realm, technical merit
is moot--and if software engineering is about anything, it's about
competing on technical merit.  (I would seek to expand this definition,
by the way.)

>Software projects are a little like Venture Capital.  You have to roll 
>the dice intelligently so that for every ten startups, you get a winner.

To complete the analogy, you'd have to tell us what the random factors
are.  You're implying that software engineering is *mostly* random
factors, heavily weighted against success by some aspect intrinsic
to the process.  At least I'm willing to try to name that weighting
factor: I think it's politics.  (Having been in several venture-financed
start-ups, I'll give you three guesses about the major failure factor
in those!)  You, on the other hand, would probably just bundle all
these risk factors into something called "complexity".  Yow!  In that
case, why bother trying?  Politics I might eventually get the hang of.
But if dominant risk factor is just pure technical complexity, then
forget it!  That isn't what I got into computers for.

By the way: please pardon the sharp tone of my comments--it's certainly
not meant personally.

---
Michael Turner
miket@tcs.com