Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!motcsd!hpda!hpcupt1!hpirs!runyan
From: runyan@hpirs.HP.COM (Mark Runyan)
Newsgroups: comp.software-eng
Subject: Re: Maintenance (was: Schedule and Budget...)
Message-ID: <9630011@hpirs.HP.COM>
Date: 24 Oct 89 19:44:33 GMT
References: <1271@accuvax.nwu.edu>
Organization: HP GSY/USO/UKL Cupertino, CA, USA
Lines: 48

>/ travis@delta.eecs.nwu.edu (Travis Marlatte) /  6:32 pm  Oct 18, 1989 /
>The discussion was kind of heading in the direction of using maintenance
>as a training vehicle for new engineers. I think most of us agree that
>this is wrong. 

It is always embarrassing to find myself in the minority.  Still, I don't
agree that "this is wrong".

>Whoops. There I said it again. The goal is create good designers. Somehow,
>to be a good programmer, I believe one has to become a good designer. 

I agree with this.

>I do think that maintenance as a training vehicle is a waste of time. The
>trainee learns nothing except how stupid past developers were. The company
>may benefit from freeing up its more highly prized programmers but there
>certainly is a cost of poorly done maintenance.

The trainee learns by seeing "how stupid past developers were"!  The
trainee sees what was done, what is available, and why certain techiniques
applied in certain ways within the company either did or didn't work.
Sounds like great training to me!  As for "poorly done maintenance", the
supervisor *must* be aware that the trainee is learning and actually
supervise the trainee, otherwise the exercise *is* a waste of resources.

>Actually, maintenance is an important part of new design as well. I can't
>count how much time I've saved by striping a piece of code from a past
>product and using it in a new design. Gosh - reusable software.

Again, this gives the trainee the chance to see what is available for
stripping with the new company.

>To reiterate my position - apprenticeships or something similar seem
>like a pretty clean way of approaching training. Note that this does
>address the new employee whether novice or experienced. Some formal program
>to help the experienced programmer fit in with the company is just as
>appropriate as a formal program to bring the novice up to speed.

I agree with this position completely.  My take is that the maintenance
organization is probably a good place to start this apprenticeship.  Some
experienced programmers may already be informed and professional enough
to join initial design teams, but to lower the learning curve on what is
available in the company and what has or hasn't worked in the past, I
believe even experienced programmers should be started in maintenance.
Of course, this opinion is purely my own and I am *not* a manager or
supervisor.

Mark Runyan