Xref: utzoo comp.sw.components:330 comp.software-eng:2156
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!accuvax.nwu.edu!delta.eecs.nwu.edu!travis
From: travis@delta.eecs.nwu.edu (Travis Marlatte)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Maintenance (was: Schedule and Budget...)
Summary: On the job training
Message-ID: <1271@accuvax.nwu.edu>
Date: 13 Oct 89 14:05:26 GMT
Sender: news@accuvax.nwu.edu
Reply-To: travis@delta.eecs.nwu.edu (Travis Marlatte)
Organization: Northwestern U, Evanston IL, USA
Lines: 49

I don't see the reasoning that novice programmers should be given the
task of maintaining existing systems. I also don't see the reasoning that
thou who creates it will maintain it even unto ball and chain.

Simple analogy: A team of crack engineers build a beautiful and structurally
sound bridge that serves its purpose well. Five years after construction,
it is learned that the foundation at one end is giving way due to water
damage. The company assigns its newest employee to the task of designing
the correction to the problem.

Sounds absurd to me! I would hope it sounds absurd to the rest of you too.
Isn't the analogy correct. Why would I want to assign inexperienced staff
to the task of shoring up existing systems? Especially, since we know that
mainenance is often a task of stretching the intent of the original design
to meet current expectations. Further, why would I want my newest employee
dedicated to mastering 5 year old technology?

Why does the idea of an apprentice not spring to mind quickly? Would it not
be better to have a junior programmer (or junior software engineer or
junior whatever) position? This position may very well get stuck with a
load of grunt work tasks. But, the work would ultimately be the
responsibility of a senior person who guides the work of the junior.

The work would then include a mix of maintencance and latest and greatest
design - whatever the senior staff was working on. By blending the work
of the past with the work of the new, the junior member gets an introductory
view of the whole picture. Technology transfer through sharing rather than
dumping - dumping unwanted, undesirable tasks on a new hire.

This type of idea can be taylored to each situation. A company developing
coin machines may have a six month apprentice program. A company developing
chemical process control might have a 5 year program.

I have a friend working as a actuary. For advancement, they have to take
a series of tests that may take up to ten years to complete. Their status
as an actuary depends on the level they have achieved in taking the tests.

While I don't think the software business is as structured as the insurance
business, my point is that a training program for newcomers should not be
shuned. It should not be embarassing to be considered a junior staff member.
Of course, there is cause to celebrate when that day comes that you are
no longer considered a junior.

By the way, my first job out of school was as a maintenance programmer
for control systems. I didn't mind doing it but it certainly was a waste
of time. Only by becoming involved in curent design effort does one come
to understand the task of doing current design.

Travis