🚀 go-pugleaf

linda@rtech.rtech.com (Linda Mundy) writes about my comment that one hard-
to-pin-down aspect of new-code quality might be:
> >..."must be able to
> >survive the next five years of changes, to meet new needs, hacked in by
>                                                             ^^^^^^^^^^^^
> >bored second-string maintenance programmers..."  ...
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

She says:
> Dick, I really agreed with the main points of your article, making the above
> remark come as a surprise.  Not picking you in particular, but this is
> such a common attitude towards maintenance programmers, I thought it might be
> appropriate as a topic of discussion in its own right...

I agree with Linda's sentiments.  Now, to be clear about why I said what I
did:  It IS a common attitude toward maintenance programmers.  It's an
unfortunate, stupid, misdirected attitude.  Not only do I NOT agree with
it; it makes me angry.  BUT it's there, and has to be reckoned with.  In
other words, I pointed out that quality software needs to survive being
hacked over by bad maintenance programmers not because maintenance SHOULD
be done that way, but because it WILL be done that way, in all likelihood.
You have to make the software a little hardier than it should need to be
in order to survive what it will be put through.

Maybe I should also have been careful with the wording so that it would
have been clear that I meant (second-string) (maintenance programmers), as
opposed to (second-string maintenance) programmers.

> 	-- do you think maintenance work is easier than development work?
Sometimes it is - routine changes may be very easy to make.  Sometimes it's
not - the effects of an apparently small change may run across the grain
and affect a large part of the code, requiring exceptional perspicacity to
keep from screwing up the code.
> 		...does your answer change for large
> 		systems vs. small systems?
My initial reaction is that it doesn't.  It changes depending on the
structure of the system.  The more interconnected a system is, the harder
some changes are.

> 	-- do you think that maintenance programming belongs lower on the
> 		"pecking order" than development programming?
As a rule, no.  However, it is usually PLACED lower in the pecking order.
Sometimes, maintenance work can be used effectively for training--in this
sense, you spend time learning an existing body of code, understanding how
things are done, seeing problems, etc., before you go create new code.
It works if it's done carefully.

> 	-- do you think that software engineers should do a stint at
> 		maintenance, or do you think that maintenance is a place to
> 		put the (perceived to be) less talented?
> 	-- do you think maintenance should be a separate function, or that
> 		developers should be responsible for maintaining their own
> 		code (as much as possible)?

All software engineers should spend time on maintenance.  Since maintenance,
in the general sense which includes modification, porting, and the like, is
MOST of what software folk spend their time doing, having people work only
on new code puts them a bit out of touch with reality.

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.

> 	-- do you think that there are different skill sets for maintenance
> 		vs. development?  if so, is one skill set "better" than
> 		another?

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.  There
are others who are better at cutting from whole cloth; they have trouble
reworking other people's code.  We should be able to accommodate these
different abilities.

> You can probably tell, you hit one of my hot buttons...

Yes, and I did so unintentionally; it seems that we're mostly in agreement.
But it's just as well.  It's a topic that needs to be dragged out into the
open periodically.  It has been realized for perhaps two decades that
maintenance tasks are perceived as "inferior" in many organizations.  It
has also been realized that this leads to poor maintenance.  But we per-
petuate those damaging stereotypes.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.