Xref: utzoo comp.sw.components:327 comp.software-eng:2149 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.sw.components,comp.software-eng Subject: Re: Schedule and budget are secondary Summary: the unpleasant realities of maintenance programming Message-ID: <16202@vail.ICO.ISC.COM> Date: 12 Oct 89 21:50:44 GMT References: <16168@vail.ICO.ISC.COM> <6693@hubcap.clemson.edu> <3807@rtech.rtech.com> Organization: Interactive Systems Corp, Boulder, CO Lines: 88 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.