Xref: utzoo comp.sw.components:329 comp.software-eng:2153
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!xylogics!barnes
From: barnes@Xylogics.COM (Jim Barnes)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Schedule and budget are secondary
Message-ID: <7402@xenna.Xylogics.COM>
Date: 13 Oct 89 12:16:26 GMT
References: <16168@vail.ICO.ISC.COM> <6693@hubcap.clemson.edu> <3807@rtech.rtech.com> <16202@vail.ICO.ISC.COM>
Sender: news@Xylogics.COM
Reply-To: barnes@Xylogics.COM (Jim Barnes)
Followup-To: comp.sw.components
Organization: Xylogics, Inc., Burlington MA
Lines: 29

In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>
>One approach is to assign people to a software project "cradle to grave."
>That is, if you write it you maintain it.  You get to take on a new project
>when the work load for the old one drops below some threshold.  This has
>an interesting incentive--if you want to work on new stuff, you may be more
>careful getting things right so you don't have to do a lot of maintenance
>time.  The approach also has a handful of flaws, but it's worth exploring
>it in some environments.

One disadvantage to this approach is that it will encourage turnover of
personnel.  "I'm tired of just doing maintenance and since I can't get
assigned to some new development, I'll just go somewhere where I CAN work on
something new."  Then you have to hire new programmers to do maintenance
anyway.

>We need to get development and maintenance to equal prestige.  There are
>people who LIKE to work on existing code, shaping it to new needs.  

I agree, but it seems that it is very hard to find these people.  Maybe
the truly good maintenance programmers do not change jobs very often.






----
  Jim Barnes (barnes@Xylogics.COM)