Xref: utzoo comp.sw.components:400 comp.software-eng:2347
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uwm.edu!mrsvr.UUCP
From: mcilree@mrsvr.UUCP (Robert McIlree)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Maintenance
Message-ID: <1409@mrsvr.UUCP>
Date: 13 Nov 89 16:14:16 GMT
References: <614@alias.UUCP>
Sender: news@mrsvr.UUCP
Followup-To: comp.sw.components
Lines: 48

From article <614@alias.UUCP>, by mherman@alias.UUCP (Michael Herman):
>> now at the point where I can make those changes. Students must learn how to make
>> a good product first. Once they have mastered that, then they can learn how to
>> enhance existing products. But by the time they get to that point, they have
>> already graduated and are in industry.
> 
> I would wager that most car machanics have never seen an assembly line
> yet they still are very effective in what they do.  I would also wager
> that software maintainers don't have to be great developers.
> 
> p.s. Let's avoid the discussion that mechanics would be better if they
>      had worked on an assembly line.  Its true.  In the same light,
>      a software maintainer would be better if they had development
>      experience.  My contention is that neither are strictly necessary.

Considering that a great deal of the entry-level people (including me
when I started out 7 years ago) begin their careers performing
maintenance and/or contributing to new versions of existing systems,
I concur that one doesn't need development experience to perform
enhancements. In fact, stints as a maintainer/integrator have
some benefits when it comes time to do a brand-new project. For
example, the software being maintained might be: a) horribly designed
or patched so many times that it isn't obvious what the design intent
was, poor documentation, etc. This imparts to the entry-level maintiner
some lessons in how *not* to design software; b) wonderfully thought-out
and designed, coded to-spec, easy to understand. This case, which is
preferable, teaches the greenhorn how good systems are developed and,
by its very example, imparts good design habits.
Case b) is a great exercise prior to starting a new project, and I
recommend it to anyone starting out in this business as the first
assignment. I've seen plenty of people fresh out of school thrown into
critical paths of a new design and fail to deliver either quality
work or work by deadline. And it was not really 100% their fault, given
their lack of experience. What might have worked instead would be a
role on an on-going project, where examples (good and bad) can be
assimilated and learned from, and contributions to the project come
a little faster than on brand-new projects.

Finally, how many of you out there in the commercial world always
work on new, start-completely-from-scratch, projects? I, in 7
years, have worked on 2 of this type (out of over 15 total). The
rest were either extensions to existing systems, integration work,
or derivatives of existing systems converted to different applications
(reuse). Thus, the ability to read and comprehend anothers code is
critical, and should really come first before trying a start-from-
scratch project.

Bob McIlree