🚀 go-pugleaf

In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
[...some discussion of "on time, under budget" vs. "quality", deleted...]

>"Quality" software is MUCH more than software which meets "the minimal
>standards of acceptability", thank you.
>
[...more good stuff deleted...]
>
>It is entirely possible to construct software which meets all such require-
>ments, but which is poorly conceived or implemented.  Examples abound.  I
>know of no way to specify software requirements such as "must be able to
>survive the next five years of changes, to meet new needs, hacked in by
                                                            ^^^^^^^^^^^^
>bored second-string maintenance programmers..."  But that's often what
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>quality software needs.
>
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.  So I ask you:

	-- do you think maintenance work is easier than development work?
		always?  sometimes? never?  does your answer change for large
		systems vs. small systems?
	-- do you think that maintenance programming belongs lower on the
		"pecking order" than development programming?
	-- do you think that such presumptions are likely to help people work
		together more effectively?
	-- 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)?
	-- do you think that there are different skill sets for maintenance
		vs. development?  if so, is one skill set "better" than
		another?

You can probably tell, you hit one of my hot buttons.  I personally think that
any new, just-out-of-school programmer should do maintenance work for awhile
(assuming, of course, that the company already has a product!)  It will
introduce them to the product they will be working on, in a context where they
can both learn and have something to show for it.  It will introduce them to
the prevailing coding style.  It will introduce them to the many pitfalls
and pratfalls that lead to bugs, thus hopefully teaching them how to avoid
same.  It may introduce them to the real-world effects of software bugs on
customers, thus improving their attitudes towards software quality.  etc., etc.  
But the most important point:  don't diminish people because of their relative
positions.  It can't do any good -- in fact, it is exactly such attitudes that
lead to "bored, second-string" employees -- wherever they happen to be in the
organizational structure.

As I said before, this is not meant as a flame, and judging by your other
statements, I doubt that we are in basic disagreement.  Of course, I could
be wrong!  (but only about the previous statement...;-))

>-- 
>Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
>   ...No DOS.  UNIX.


-- 
"Who are you to tell me to question authority?"

Linda Mundy	{ucbvax,decvax}!mtxinu!rtech!linda