Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!pdn!dinsdale!reggie
From: reggie@dinsdale.nm.paradyne.com (George W. Leach)
Newsgroups: comp.software-eng
Subject: Re: Bootstrapping a group of programmer into engineers
Keywords: transform, methods, practice
Message-ID: <6913@pdn.paradyne.com>
Date: 8 Jan 90 13:34:42 GMT
References: <15413@well.UUCP>
Sender: usenet@pdn.paradyne.com
Reply-To: reggie@dinsdale.paradyne.com (George W. Leach)
Distribution: comp
Organization: AT&T Suncoast Division, Largo FL
Lines: 56

In article <15413@well.UUCP> berger@well.UUCP (Robert J. Berger) writes:

>I have a situation where I have inhereted a team that is made up of
>programmers who call themselves software engineers. Unfortunatly they
>know nothing about software engineering.  Worse is that they don't know
>they don't know anything about software engineering.

    Titles can be very misleading in this industry.  This still proves
that the demand for skilled professionals far outstrips the supply....

>Concepts of product lifecycle, design documents, schedules, testing
>plans, metrics, reusablity, portability, etc are alien concepts that
>have no place in their rush to write code. Software Quality methods and
>concepts are of no use to them. The words sustaining and maintenance
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>draw blank stares.
 ^^^^^^^^^^^^^^^^^

     Ah, here is a key clue to the solution.

>The product they have produced reflects this mentality. It is huge in
>terms of number of lines of code. Much larger than is needed to
>accomplish the task.  It looks to be virtually unmaintainable as there
>is absolutely no formal spec, no design documents, etc.

     Who has to maintain this stuff?  It doesn't sound like the original
group does.

>My question is, Does anyone know of a videotape or small easy to digest
>book or article that communicates the down side of bottom up random
>hacking and the up side of engineering? Something that would clearly 
>demonstrate the win of planning, testing, software Quality orientations.
>I am particularly interested in examples in the embedded systems realm as
>opposed to the Data Processing MIS realm.

     No, nothing worthwhile.  Take that group and put them into a maintenance
role.  Make sure they maintain code that is equally as bad as theirs is.  But
make sure it was not written by them.  The original programmers are not 
available, there is no documentation, etc......  Give them a taste of their
own medicine.  It *IS* the *ONLY* way they will learn.

>How have other people dealt with transforming a team of narrow minded 
>prima donna programmers into engineers? Is it doable?

    My impression is that this is quite difficult.  You need people
who not only have been trained as engineers, but also believe in the
techniques and philosophy as well.  Your problems are not so much one
of lack of education (or I should say ability to learn) as they are a
lack of desire to change.

George

George W. Leach					AT&T Paradyne 
(uunet|att)!pdn!reggie				Mail stop LG-133
Phone: 1-813-530-2376				P.O. Box 2826
FAX: 1-813-530-8224				Largo, FL 34649-2826 USA