Xref: utzoo comp.sw.components:402 comp.software-eng:2354 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!apollo!perry From: perry@apollo.HP.COM (Jim Perry) Newsgroups: comp.sw.components,comp.software-eng Subject: Re: Maintenance Keywords: knowledge, expectations, fairness Message-ID: <46d165bf.20b6d@apollo.HP.COM> Date: 13 Nov 89 20:52:00 GMT References: <1337@accuvax.nwu.edu> <11064@cbnews.ATT.COM> <78584@linus.UUCP> <376@cherry5.UUCP> Sender: root@apollo.HP.COM Reply-To: perry@apollo.HP.COM (Jim Perry) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 66 In article <376@cherry5.UUCP> murphyn@cell.mot.COM (Neal P. Murphy) writes: Various real-world analogies such as: > Could you add a manual choke cable to your car's engine? I don't follow the basic analogy -- are you postulating a class of people who are sufficiently trained in automotive engineering to design an engine, but not sufficiently trained to install a choke cable in one? >Students are in a similar position. While they have may have solidly mastered >the basics, they have yet to learn how to make a good, fine, large software >system. They couldn't possibly learn enough about the system to be modified to >properly make the changes. I've been in this field for 10 years, and *I've* >just spent a month and a half reading 500 pages of source code and 500 pages of >documentation just to add features X and Y to a product here at Motorola. I am >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 must disagree with some of the assumptions here. I believe that if the software in question is correctly engineered, then a competent student with a solid mastery of the basics should be able to perform simple maintenance on that system. This assumes, by the way, that "the basics" includes some knowledge of what constitutes "correct engineering". Unfortunately, this is not the case, and I've seen very few real-world systems that are in fact engineered to such a standard. Within that constraint, I'll agree that making significant changes to a system that is inadequately documented, not clearly structured, etc. can stretch the abilities of the most capable programmer. Without any knowledge of the system you are dealing with or the complexity of "X and Y", I'll venture to state that there are things the previous writers/maintainers of the system could have done that would have made it easier, probably significantly easier, for you to make your changes. Students can't learn to make a good product if they don't know what one is. A major component of what makes a product good is its maintainability. To be able to write a program that does what it is intended to do, and do it well (by whatever metric) is important, but it is also important that others be able to easily alter it later. There is generally some perception that this is desirable, but without hands-on experience maintaining other people's code, things like commenting, roadmaps, design documentation, and the like are just rules to be followed (and, like as not, dropped as soon as they're not being graded on). This doesn't address the problem of coming up with example systems to make these maintenance assignments on, I admit that's tough. Of course ideally there would be two versions of the assignment: the first time, making a minor change on a typical (i.e. not bad or buggy, just not engineered for continuing maintenance) system, the next assignment to make a change of a similar magnitude to a fully-engineered, well-documented system. [In my day, before the goto wars had been fought and won, there was typically an assignment early on to make some change to (or just decipher) a "spaghetti-code" program, contrasted with the "structured" version; this is a similar exercise at the software engineering level]. One possibility that seems somewhat promising: in a class which has a longterm ongoing project (a compiler, perhaps), have students swap off source code at each iteration, so each increment of change is to someone else's code. It would be best if the project were such that considerable variation in design and structure were possible, so that your predecessor's code might not be structured just like yours. Needs some development, and I should get back to work... - Jim Perry perry@apollo.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.