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

In article <1992Oct13.122727.10076@afit.af.mil> jcardow@afit.af.mil (James E. Cardow) writes:
>
>On the plane ride home from the conference I read a book that a friend
>in Ops Research was really hot on.  It was a management book, and it has
>been a while since I opened one, but he really thought this was special,
>so I thought it would kill some long hours.  The book is called "the
>Goal: A Process of Ongoing Improvement" by Eliyahu Goldratt.  It is
>written as a novel, about a factory about to close.  The bottom line is
>the manager saves the factory (etc. etc).

I ran across this one quite by accident some years back, and read it in
one sitting.  I started sometime after lunch, and next time I looked up
it was dark outside.  Very compelling reading for the average engineer-
workaholic (which I suppose I still am, at least at heart.)

> 				          ...But some things came up that
>at first I though weren't related to software engineering.  The most
>fundamental was a simple question related to the title, what is the
>goal?  In this factory, the goal turns out to be the common sense answer
>of making money, but when you look at how the goal had been approached,
>it wasn't clear that anyone had the goal in mind.  I really can't convey
>the message well here, but let me ask this.  
>
>	What is the GOAL of software engineering?

To me the real VALUE of software is in how it can or might enhance
RAPID COMMUNICATION.  Increasingly, I believe that this value is in
at least partial conflict with the GOAL of most people commissioning
software projects: INSTANTANEOUS CONTROL.  (Of course, it can also
help towards this goal.)

The goal of a factory might be to make money (and to continuously improve
process in order to continue making money when competing with others
who are also continuously improving.)  Software, in the final analysis,
doesn't make money.  Software communicates information.  Most software
projects are initiated by middle managers, who are paid to control.
Information systems can help or hinder them in pursuit of control.
I believe that many projects are started with the illusion that the
software will enhance control, whereas the reality is that the system 
will create as many control problems as it solves.  The "morning-after"
realization problems dooms many projects, and can hit at any of
several stages.

Maybe the reason that so many bad systems are created with so little
planning is that these shoot-from-the-hip systems are more likely
to get premature management commitment (from those shoot-from-the
hip  clients thirsty for intantaneous control) than the more carefully
and tentatively planned systems.

Management that decides to go slow and really look at how computers
might or might not solve their communications and control problems,
by working out detailed requirements and doing careful design reviews,
might too often see that computers aren't really going to help.

I think that if things are going to change, software engineering
is going to have to come to grips with this.  We have to be willing
to go in and say, NOT that our system will be better than the other
guy's, but that NO system might be better than ANY system.  To be
willing to be paid NOT for how many jillions of lines of code our
"methodology" can produce in unit time, but sometimes just to help
answer the question: do you even need software at all?  And how
*little* of it can you get by with?  This takes a level of honesty,
humility and accountability that, in my experience so far, is rare.
---
Michael Turner
miket@tcs.com
Newsgroups: comp.software-eng