Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!gatech!purdue!haven!mimsy!jogger.cs.umd.edu!straub
From: straub@jogger.cs.umd.edu (Pablo A. Straub)
Newsgroups: comp.software-eng
Subject: Re: Not engineers
Message-ID: <33297@mimsy.umd.edu>
Date: 20 Apr 91 14:04:00 GMT
References: <1991Apr17.144402.16637@sparky.IMD.Sterling.COM> <684@tivoli.UUCP>
Sender: news@mimsy.umd.edu
Reply-To: straub@cs.umd.edu (Pablo A. Straub)
Organization: U. of Maryland, Computer Science Dept., College Park, MD 20742
Lines: 40

In article <684@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes:
> [...]
> No no, this [borrowing terminology from the entertainment industry] is
> actually a VERY good idea to explore.
> 
> AIM does software for CD-I, the interactive version of CD laser  tech.
> sponsored  by Sony, Polygram, and Philips. Their software products are
> mostly games and educational programs, and since their backing is from
> the entertainment industry they naturally gravitated  towards  what  I
> call  the  Hollywood Model (c). They have a Producer (the Finance guy,
> usually), the Director  (the  Development  or  Project  Manager),  the
> Writers  (software developers), and the Artists/Graphics people (which
> would, I suppose, correspond to GUI programmers and designers).

This may be a great idea in an  organization  that  develops  games  and
educational  programs, for after all the end product is like that in the
entertainment industry.  Software that will be  used  directly  by  many
people (e.g., a spreadsheet for a microcomputer) might probably fit this
mold  too.  Attempting  to  generalize this scheme to all other software
products (e.g., custom software, engineering software) is at least naive
and at worst irresponsible.

> IMHO, the term "software engineer" was  both  a  sign  of  hope  (that
> programmers  would  live up to the term) and an acknowledgement of the
> increasing complexity of interrelated  software  components  requiring
> more engineering skill sets.

Agree.

> As Tom Peters has said, "try it, break it, fix, repeat." Organizations
> should be free  to  experiment,  SO  LONG  AS  THEIR  STAFFS  ARE  NOT
> THREATENED AND YOU GET BUY-IN.

But an engineering approach to experimentation must  be  guided  by  the
organizations'  goals,  not  just  the  curiosity  of  individual  staff
members.


Pablo A. Straub
straub@cs.umd.edu