travis@delta.eecs.nwu.edu (Travis Marlatte) (10/13/89)
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
phil@attctc.Dallas.TX.US (Phil Meyer) (10/14/89)
In article <1271@accuvax.nwu.edu> travis@delta.eecs.nwu.edu (Travis Marlatte) writes: > >Why does the idea of an apprentice not spring to mind quickly? Travis has a good point here. The analogy to a wizard's apprentice is even better. How do you become a wizard? By studying with/for a wizard. (or rather, what is the BEST way) We must also cultivate a love of the craft. This is the real difference between being bored (in any position) and being happy with the workload. Many really good programmers do it because they couldn't think of doing anything else. "Give me a workstation and a place to sit, and I'm happy." is a common attitude among the wizards I have known. The specific task, whether it be maintainance or design, is seldom mentioned. But rather, the usuall conversations amongst these people lean towards new constructs, difficult passages, tools, the latest and greatest hardware, etc. etc. +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Honesty is in the eye of | Phil Meyer | | the creditor. | Usenet: <backbone>!attctc!lodestar!phil | | | VoiceNet: (214) 991-0897 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
itkin@mrspoc.Transact.COM (Steven M. List) (10/19/89)
travis@delta.eecs.nwu.edu (Travis Marlatte) writes: >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. This seems awfully absolute. I didn't hear anyone make either of these statements as absolutes. In fact, as regards the second statement, it was specifically mentioned as an option. There are MANY people who find the option to have responsibility for and commitment to a project from "womb to tomb" VERY attractive. There are others (myself included) who like to do a certain amount of work on a project and then move on to some- thing else. The threshhold varies, but the desire tends to be one for change and variety. >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. I notice that Travis said "newest employee", not "novice engineer" or "recent graduate." >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? Sounds absurd to me too. No one said that was the idea. The idea is that through working on fixing bugs (maybe major, maybe not), a new employee (not necessarily junior, however!!!!) can learn the systems, the techniques, and the standards and approach used by his/her new employer. While we tend to think of YOUNGER employees when we think of NEWER employees, this is CLEARLY not the case. When you change jobs, do you expect to walk into your new job and immediately start designing their hottest project? While it does happen, it is the exception rather than the rule. New employees have to learn their way around; socially, organizationally, and professionally. In our profession, this is frequently accomplished by putting the employee to work on low- to medium-priority maintenance tasks. > [ lots of interesting stuff about apprenticeship approaches ] I agree that apprenticeship is a terrific way to progress. Once again, I must point out that NEW employee does not translate to RECENT GRADUATE or YOUNG. Put the issue in perspective. >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. "A waste of time." Does this let everyone know what Travis thinks of maintenance and programmers who DO maintenance? Obviously what is important and interesting to Travis is design and being in on the ground floor of a project. While that's true of many of us, we also learn to appreciate the time we get to work on maintenance. It can be a wonderful break from the pressure and pace of being at the front end. Like doing gardening or cooking or folding laundry. Like doing manual labor after programming all day. Change. Nurture versatility and an appreciation for ALL aspects of your profession, and you will BE a professional. -- +----------------------------------------------------------------------------+ : Steven List @ Transact Software, Inc. :^>~ : : Chairman, Unify User Group of Northern California : : {apple,coherent,limbo,mips,pyramid,ubvax}!itkin@guinan.Transact.COM :
travis@delta.eecs.nwu.edu (Travis Marlatte) (10/19/89)
The discussion was kind of heading in the direction of using maintenance as a training vehicle for new engineers. I think most of us agree that this is wrong. Exposure only to maintenance is probably not the way to bring a new programmer up to speed for design. Whoops. There I said it again. The goal is create good designers. Somehow, to be a good programmer, I believe one has to become a good designer. Even in maintenance, and we all know I think that job is scum, good design techniques are paramount to making sound revisions - whether defect fixes or enhancements. Contrary to my sarchastic comment above, I love maintenance. I have always been one to enjoy tearing something apart, figuring out how it works, and how to make it work better. I would think that most engineers have this same attitude. I do think that maintenance as a training vehicle is a waste of time. The trainee learns nothing except how stupid past developers were. The company may benefit from freeing up its more highly prized programmers but there certainly is a cost of poorly done maintenance. Actually, maintenance is an important part of new design as well. I can't count how much time I've saved by striping a piece of code from a past product and using it in a new design. Gosh - reusable software. To reiterate my position - apprenticeships or something similar seem like a pretty clean way of approaching training. Note that this does address the new employee whether novice or experienced. Some formal program to help the experienced programmer fit in with the company is just as appropriate as a formal program to bring the novice up to speed. A few comments on licensing: (are you out there Ms. Richards?) Licensing does not prove competence or ability. It merely transfers liability. And that usually doesn't work either. Licensing should mean nothing to a fellow programmer (or engineer). It is only a stamp of approval from a publicly recognized body and it is for the benefit of the public. Licensing can only be used as a first defense against blithering idiots passing themselves off as professional programmers. I am quite confident that the programmers responsible for recent widely publicized software failures were nothing but professionals and would have gained a license if such were required. Travis
rcd@ico.isc.com (Dick Dunn) (10/19/89)
Noted in passing in an article from itkin@mrspoc.Transact.COM (Steven M. List): > ...When you change jobs, do you expect to walk into > your new job and immediately start designing their hottest project? While > it does happen, it is the exception rather than the rule... Even more than the needs which List outlined (listed?:-) to get the new employee oriented and familiar with what's going on, establish continuity, etc., there's an important reason not to hire new employees and start them right off on a new project (or, especially, to staff up a new project with all new people): New projects are usually perceived as being more fun, more rewarding, more relevant, etc. What sort of a message does it send to the employees who have been around for a while?! "Oh...I see...I'd get a new project if I were a new employee. I know how to solve that!" It's the best way to start a process of flushing people through the company. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
robert@isgtec.UUCP (Robert Osborne) (10/20/89)
In article <1337@accuvax.nwu.edu> travis@delta.eecs.nwu.edu (Travis Marlatte) writes: >The discussion was kind of heading in the direction of using maintenance >as a training vehicle for new engineers. I think most of us agree that >this is wrong. Exposure only to maintenance is probably not the >way to bring a new programmer up to speed for design. I think a small bug or new piece of functionality is the best way to bring somebody up to speed. The new engineer MUST be guided by a experienced engineer throughout this experience. However, leaving somebody in maintenence for a long time is probably a good way to kill morale and enthusiasm. >I do think that maintenance as a training vehicle is a waste of time. The >trainee learns nothing except how stupid past developers were. The key is to make the trainee *SEE* what bad design, habits, styles, whatever do to a maintenance effort, and just what bad design etc. *IS*. Of course if the trainee is modifying my stuff they get to see a great implementation of a good design :-). >Actually, maintenance is an important part of new design as well. I can't >count how much time I've saved by striping a piece of code from a past >product and using it in a new design. Gosh - reusable software. Exactly, get them to explore the system and see what there is out there for them to steel. >A few comments on licensing: >[...] It merely transfers liability. [...] >[...] It is only a stamp of approval from a publicly >recognized body and it is for the benefit of the public. It also gives you somebody to pin the blame on and to sue :-(. Like an civil engineer (at least in Ontario) must stamp building plans, and if it falls down they catch it (bad pun intended :-). > >Travis Rob. -- Robert A. Osborne ...uunet!mnetor!lsuc!isgtec!robert (Nice sig Bruce mind if I steal it :-) ...utzoo!lsuc!isgtec!robert ISG Technologies Inc. 3030 Orlando Dr. Mississauga. Ont. Can. L4V 1S8
UH2@PSUVM.BITNET (Lee Sailer) (10/20/89)
One hears the phrase, "Maintenance through redesign." The idea is that to
modify a program, one goes back to the analysis and design documents, e.g.,
Data Flow Diagrams, Logical Data Models, Structure Charts, or whatever and
makes the modifications there, moving step by step through the entire process
til the coding stage is reached.
On the other hand, to many practitioners, maintenance means jumping in and
hacking the code.
It seems to me that the first type of M-- would be very educational, and a good
way to bring a new hire up to speed on local customs, the nature of the
system, and so forth.
leerunyan@hpirs.HP.COM (Mark Runyan) (10/25/89)
>/ travis@delta.eecs.nwu.edu (Travis Marlatte) / 6:32 pm Oct 18, 1989 / >The discussion was kind of heading in the direction of using maintenance >as a training vehicle for new engineers. I think most of us agree that >this is wrong. It is always embarrassing to find myself in the minority. Still, I don't agree that "this is wrong". >Whoops. There I said it again. The goal is create good designers. Somehow, >to be a good programmer, I believe one has to become a good designer. I agree with this. >I do think that maintenance as a training vehicle is a waste of time. The >trainee learns nothing except how stupid past developers were. The company >may benefit from freeing up its more highly prized programmers but there >certainly is a cost of poorly done maintenance. The trainee learns by seeing "how stupid past developers were"! The trainee sees what was done, what is available, and why certain techiniques applied in certain ways within the company either did or didn't work. Sounds like great training to me! As for "poorly done maintenance", the supervisor *must* be aware that the trainee is learning and actually supervise the trainee, otherwise the exercise *is* a waste of resources. >Actually, maintenance is an important part of new design as well. I can't >count how much time I've saved by striping a piece of code from a past >product and using it in a new design. Gosh - reusable software. Again, this gives the trainee the chance to see what is available for stripping with the new company. >To reiterate my position - apprenticeships or something similar seem >like a pretty clean way of approaching training. Note that this does >address the new employee whether novice or experienced. Some formal program >to help the experienced programmer fit in with the company is just as >appropriate as a formal program to bring the novice up to speed. I agree with this position completely. My take is that the maintenance organization is probably a good place to start this apprenticeship. Some experienced programmers may already be informed and professional enough to join initial design teams, but to lower the learning curve on what is available in the company and what has or hasn't worked in the past, I believe even experienced programmers should be started in maintenance. Of course, this opinion is purely my own and I am *not* a manager or supervisor. Mark Runyan
dalamb@qucis.queensu.CA (David Lamb) (11/09/89)
Requiring students to do some form of maintenance as assignments has some very good educational benefits. - It motivates a lot of the "readability" guidlines we give them in a way that makes a lot more sense to students than just because readability is part of the grading scheme - It motivates the need for design documentation to help students understand large systems. - In anything in which it is possible to be literate, there exists a "literature" with which one ought to be familiar. Literacy in programming should require students to be familiar with well-known concepts; reading real (well-chosen) programs is a good way to do so. Unfortunately it's difficult for faculty members to get credit for developing such examples, or for spending the effort to find or tailor "real" ones that match well with the desired educational objectives. David Alex Lamb Department of Computing and Information Science Queen's University Kingston, Ontario, Canada K7L 3N6 (613) 545-6067 ARPA Internet: David.Lamb@cs.cmu.edu dalamb@qucis.queensu.ca uucp: ...!utzoo!utcsri!qucis!dalamb
richard@pantor.UUCP (Richard Sargent) (11/09/89)
Received: by pantor.UUCP (UUL1.3#5109)
from becker with UUCP; Wed, 8 Nov 89 23:04:32 est
Path: becker!censor!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!spdcc!merk!alliant!linus!community-chest!mitchell
From: mitchell@community-chest.uucp (George Mitchell)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Maintenance
Message-ID: <78584@linus.UUCP>
Date: 7 Nov 89 20:02:20 GMT
References: <1337@accuvax.nwu.edu> <11064@cbnews.ATT.COM>
Sender: news@linus.UUCP
Reply-To: mitchell@community-chest.UUCP (George Mitchell)
Organization: MITRE-McLean Software Engineering Laboratory
Lines: 12
In article <11064@cbnews.ATT.COM> kww@cbnews.ATT.COM
(Kevin W. Wall,55212,cb,1B329,6148604775) writes: `Just once I'd
`like to see a homework assignment in some CS course be something like
`
` "add features X and Y to this 60,000 software system (which the
` students have never seen before) and turn it in next week".
Would someone (or more) please address why this is not done.
--
/s/ George vmail: 703/883-6029
email: mitchell@community-chest.mitre.org [alt: gmitchel@mitre.arpa]
snail: GB Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102
About a year ago, I read a paper in a periodical about a university
prof who did a teaching experiment on this. Unfortunately, I can't
find, nor recall, the periodical!
The work involved modifying a mail system. The gist of the article
was that the technique worked, but it is very difficult to
establish a suitable problem environment which fits the structure
and timing available in a university semester.
As for when this kind of teaching will be widespread, please
remember that *any* organization larger than, oh say, 10 people
is incapable of reacting very quickly to changes. The larger
the organization, the slower the reaction. A single university
is pretty large. The entire education system is very large.
It will come. In the meantime, there are education programs like
the one pioneered by the University of Waterloo, called co-operative
education. The premise is that students attend one semester of
classes, then work for one semester for a company whose business
is related to the student's field of study, and repeat for a total
span of 5 years instead of 4 to cover a 4 year degree program.
The result? Graduates who don't suffer from "ivory-tower-itis",
who have almost 2 years relevant work experience in their chosen
profession, and who are not in debt to their eyeballs, and whose
parents can afford to send their second born to university, too.
These co-op programs are becoming very widespread. Waterloo was
founded as an engineering school in 1957 and started co-op
studies immediately upon founding. Now it is regarded as one of
the foremost schools for computer science in North America.
I guess it is also fair to say that detractors claim the co-op
program breeds yuppies, that the students have no sense of fun,
and on and on. Needless to say, I disagree completely.
Richard Sargent Internet: richard@pantor.UUCP
Systems Analyst UUCP: uunet!pantor!richardmurphyn@cell.mot.COM (Neal P. Murphy) (11/09/89)
In article <78584@linus.UUCP> mitchell@community-chest.UUCP (George Mitchell) writes: >In article <11064@cbnews.ATT.COM> kww@cbnews.ATT.COM >(Kevin W. Wall,55212,cb,1B329,6148604775) writes: `Just once I'd >`like to see a homework assignment in some CS course be something like >` "add features X and Y to this 60,000 software system (which the >` students have never seen before) and turn it in next week". > >Would someone (or more) please address why this is not done. There is a very good reason this is not done. Could you add a manual choke cable to your car's engine? (Assuming it has a carb, not fuel injection.) Could you install, to code requirements, a 20A electrical circuit to your house? Could you ski Tuckerman Ravine from above the Lip to the bottom of the Headwall? (Tuckerman is on Mt. Washington, NH) If you can, great! But think of the millions of people who break into a sweat if they have to open the hood of their car, replace a fuse in their fusebox, or walk to the corner store after a 4 inch snowfall. It wouldn't be fair to expect any of these people to perform the specialized tasks I mentioned above, because they have barely mastered the basics. 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. BTW, I've added manual chokes to several cars, I've wired in several circuits (to code), and I fell off the lip at Tuckerman while hiking last April. I'll ski it the next time. And, due to the good grace of cabinet maker, back in Massachusetts, who gave me a chance and was willing to teach me, I am also a cabinet maker. (No boast, just fact.) All that and a BSCS to boot. NPN
amull@Morgan.COM (Andrew P. Mullhaupt) (11/09/89)
In article <78584@linus.UUCP>, mitchell@community-chest.uucp (George Mitchell) writes: > In article <11064@cbnews.ATT.COM> kww@cbnews.ATT.COM > (Kevin W. Wall,55212,cb,1B329,6148604775) writes: `Just once I'd > `like to see a homework assignment in some CS course be something like > ` > ` "add features X and Y to this 60,000 software system (which the > ` students have never seen before) and turn it in next week". > > Would someone (or more) please address why this is not done. > -- There are a few important reasons why this is not done often in CS courses. 1. The proper subject material for routine courses must be in some sense widely received and well-understood material. It is not a good idea to give an assignment like this unless you can really treat the issues that may come up. The methods that are being developed for dealing with this problem seem to me controversial. From an academic point of view, one may very well argue that the 60,000 line system can either be treated in a localized, (i.e. weakly interacting pieces much less than 60,000 lines long) manner. If this is not the case, then one can argue that the system is much more seriously flawed than lacking features 'X and Y'. One might also encounter the belief that if features 'X' and 'Y' are not easily implemented and it's hard to figure out what the 60,000 lines of code really do (in detail) then it may not be safe or acceptable to add 'X' and 'Y'. It will not satisfy the students to tell them that the real world is like this, and they will have to do sub-sensible compromises as professionals. You will have to (if you are an intellectually honest professor) arrive at a good example of a 60,000 line piece of code, not fatally flawed from the start, and desirable missing features 'X' and 'Y'. Whitewashing the unretouched output of some code generator generator is not likely to teach your students very much other than this type of work should be avoided. 2. The project may not fall within the grasp of even good undergraduate students. Their curriculum needs to treat other important issues first, such as basic programming, fundamental algorithms, data structures, formal languages, operating systems, computer architecture, compilers and interpreters, and principles of software design (including ideas of correctness, performance, and specification). It is not clear to me that you can expect two full semesters in each of these, and I don't think there is room for the large-scale maintenance problem in the first semester of any of them. So perhaps this is for graduate students. 3. As for graduate school, you might give such an assignment, but in the universities where I have been a professor (University of New Mexico, State University of New York at Buffalo), students were acquiring enough experience not to need this assignment or they were hopeless enough not to profit by it. The people in my experience who had the greatest difficulty dealing with large scale assignments were the people who worked full time as systems programmers at the computer center: their problem was often that they knew how much sleaze was out there 'in the real world' and they were trying to get away with a widespread but unacceptable practice where a well founded solution was equally near at hand. 90% of the code in the world is written by people not fit to teach the language they code in, especially at the graduate level, which means that often the only lesson reliably drawn from real world code is how much computer science has advanced since the authors of the real world code were educated. 4. The 60,000 line program is likely to seem to graduate students like a program they are developing/maintaining for the benefit of the professor if the program is real. There have often been cases where a graduate computer science department has arrived at a large scale piece of software as the result of countless hours of graduate labor. In order for this to be a fair arrangement, the software work should be paid for, perhaps in terms of a research assistantship or stipend, which is not generally available to all students. Then the students who have not been awarded support should not be required to contribute work to such projects, and yet they should not be excluded from any courses simply because they are not supported. Thus the large scale program maintenance should not be in a course. It is likely that those students interested in software maintenance will seek to work for a professor who will provide them with this kind of experience, so although this kind of work belongs outside a course, it is often found in a serious computer science department. Later, Andrew Mullhaupt P. S. I was a professor of applied mathematics, with a large amount of my work in computation, but I still count my code in the 90% written by non-experts in the language because I am required (by the circumstances of my present employment) to write code in APL, a language I am philosophically opposed to. I don't think my code is bad, but you would learn a somewhat idiosyncratic style of APL if you read mine.
peterd@cs.washington.edu (Peter C. Damron) (11/10/89)
In article <78584@linus.UUCP> mitchell@community-chest.UUCP (George Mitchell) writes: >In article <11064@cbnews.ATT.COM> kww@cbnews.ATT.COM >(Kevin W. Wall,55212,cb,1B329,6148604775) writes: `Just once I'd >`like to see a homework assignment in some CS course be something like >` >` "add features X and Y to this 60,000 software system (which the >` students have never seen before) and turn it in next week". > >Would someone (or more) please address why this is not done. It is done here at Univ. of Washington. The students in the undergraduate compiler class are given a working compiler and add features to it. Of course, the compiler they are given is only about 50-70 pages of code and is well modularized, so it is a managable size to learn in a couple weeks. Just thought you'd like to know, Peter. --------------- Peter C. Damron Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195 peterd@cs.washington.edu {ucbvax,decvax,etc.}!uw-beaver!uw-june!peterd
jrj1047@ultb.UUCP (J.R. Jarrett) (11/10/89)
In article <295@qusuntrc.queensu.CA> dalamb@qucis.queensu.CA (David Lamb) writes: >Unfortunately it's difficult for faculty members to get credit for developing >such examples, or for spending the effort to find or tailor "real" ones that >match well with the desired educational objectives. Plus, industry is VERY touchy about allowing their code (even their bad code) out for fear that they will be giving up some "proprietary secret". There's only so many ways you can calculate pay...... -- +-------------------------------------------------------+ | Jim Jarrett, Rochester Institute of Technology | | (716) 271-7019 jrj1047@ultb.isc.rit.edu | +---------------- rutgers!rochester!ritcv!ultb!jrj1047 +
mherman@alias.UUCP (Michael Herman) (11/12/89)
> 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 would wager that most car machanics have never seen an assembly line yet they still are very effective in what they do. I would also wager that software maintainers don't have to be great developers. p.s. Let's avoid the discussion that mechanics would be better if they had worked on an assembly line. Its true. In the same light, a software maintainer would be better if they had development experience. My contention is that neither are strictly necessary.
mitchell@community-chest.uucp (George Mitchell) (11/13/89)
In article <376@cherry5.UUCP> murphyn@cell.mot.COM (Neal P. Murphy) wrote:
`
`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.
`
This appears to address the quantitative rather than the qualitative
issue. Certainly the size and difficulty of an assignment must be
appropriate for the level and scope of the course. However, it is not
apparent (to me) why writing code "from scratch" is superior to
modifying code (good and bad) as a method for learning "how to make a
good product". Indeed, it has been easier for me to learn both methods
and languages when significant portions of code were available as
examples.
--
/s/ George vmail: 703/883-6029
email: mitchell@community-chest.mitre.org [alt: gmitchel@mitre.arpa]
snail: GB Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102mcilree@mrsvr.UUCP (Robert McIlree) (11/14/89)
From article <614@alias.UUCP>, by mherman@alias.UUCP (Michael Herman): >> 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 would wager that most car machanics have never seen an assembly line > yet they still are very effective in what they do. I would also wager > that software maintainers don't have to be great developers. > > p.s. Let's avoid the discussion that mechanics would be better if they > had worked on an assembly line. Its true. In the same light, > a software maintainer would be better if they had development > experience. My contention is that neither are strictly necessary. Considering that a great deal of the entry-level people (including me when I started out 7 years ago) begin their careers performing maintenance and/or contributing to new versions of existing systems, I concur that one doesn't need development experience to perform enhancements. In fact, stints as a maintainer/integrator have some benefits when it comes time to do a brand-new project. For example, the software being maintained might be: a) horribly designed or patched so many times that it isn't obvious what the design intent was, poor documentation, etc. This imparts to the entry-level maintiner some lessons in how *not* to design software; b) wonderfully thought-out and designed, coded to-spec, easy to understand. This case, which is preferable, teaches the greenhorn how good systems are developed and, by its very example, imparts good design habits. Case b) is a great exercise prior to starting a new project, and I recommend it to anyone starting out in this business as the first assignment. I've seen plenty of people fresh out of school thrown into critical paths of a new design and fail to deliver either quality work or work by deadline. And it was not really 100% their fault, given their lack of experience. What might have worked instead would be a role on an on-going project, where examples (good and bad) can be assimilated and learned from, and contributions to the project come a little faster than on brand-new projects. Finally, how many of you out there in the commercial world always work on new, start-completely-from-scratch, projects? I, in 7 years, have worked on 2 of this type (out of over 15 total). The rest were either extensions to existing systems, integration work, or derivatives of existing systems converted to different applications (reuse). Thus, the ability to read and comprehend anothers code is critical, and should really come first before trying a start-from- scratch project. Bob McIlree
jharkins@sagpd1.UUCP (Jim Harkins) (11/14/89)
In article <78584@linus.UUCP> mitchell@community-chest.UUCP (George Mitchell) writes: >In article <11064@cbnews.ATT.COM> kww@cbnews.ATT.COM >(Kevin W. Wall,55212,cb,1B329,6148604775) writes: `Just once I'd >`like to see a homework assignment in some CS course be something like >` >` "add features X and Y to this 60,000 software system (which the >` students have never seen before) and turn it in next week". > >Would someone (or more) please address why this is not done. Because the first thing the students would do is print out the entire source and the university doesn't want to spend $30 for paper and $15 for a printer ribbon. I'm not kidding, I try to always have up-to-date source listings in notebooks for whatever I'm working on, it makes life much easier. Not to mention the disk space required to hold x copies of the source (you expect students to use links?), and CPU time required to compile all those changes. Not that it isn't a good idea, I think it's a great idea. But not practical for universities as they are currently set up. Hell, the UNIX system I have to use at school now doesn't even have a debugger (the vender never got around to porting it before going toes up) so how would you debug it? jim "Wolverine -- sex and violence without the sex"
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/14/89)
In article <614@alias.UUCP> mherman@alias.UUCP (Michael Herman) writes: >I would wager that most car machanics have never seen an assembly line >yet they still are very effective in what they do. I would also wager >that software maintainers don't have to be great developers. > >p.s. Let's avoid the discussion that mechanics would be better if they > had worked on an assembly line. Its true. In the same light, > a software maintainer would be better if they had development > experience. My contention is that neither are strictly necessary. Even under your restrictions, what you have stated is quite untrue for a very large class of systems. In these MCCR systems, most of the 'maintenance' effort is devoted to enhancing these long-lived systems, not in removing design or production errors or in restoring the product to its original performance. Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
perry@apollo.HP.COM (Jim Perry) (11/14/89)
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.
paulb@minster.york.ac.uk (11/15/89)
In article <78584@linus.UUCP> you write: >In article <11064@cbnews.ATT.COM> kww@cbnews.ATT.COM >(Kevin W. Wall,55212,cb,1B329,6148604775) writes: `Just once I'd >`like to see a homework assignment in some CS course be something like >` >` "add features X and Y to this 60,000 software system (which the >` students have never seen before) and turn it in next week". > >Would someone (or more) please address why this is not done. I can't speak for American universities (or even British universities in general), but at Durham, we are given problems of the type above. In my year there was a software maintenance workshop in which students had to both debug and add functionality to a full size compiler. If it's not done elsewhere, it should be. Paul Butcher JANET:paulb@uk.ac.york.minster
mjl@cs.rit.edu (11/15/89)
perry@apollo.HP.COM (Jim Perry) writes: > >Students can't learn to make a good product if they don't know what one is. Excellent point! And, of course, most introductory textbooks do not give particularly good examples. Not because the authors are necessarily bad designers, but because the constraints of teaching a 1st year student Pascal/Modula/whatever mean that the programs emphasize micro-concepts (this is an IF, this is a WHILE, etc.). The commenting strategies also reflect these realities -- anyone who really wrote comments the way textbooks show them should be shot. for an excellent discussion of these issues, see Henry Ledgards "Professional Software" books (Vol. I on Software Engineering and Vol. 2 on Programming Practice. Vol. 2 has a chapter titled "Comments: The Reader's Bridge," and while I disagree with some of Ledgard's specific examples, I do like his overall philosophy of appropriate internal documentation. So perhaps in 2nd level courses the professors should make available programs they consider well-written. In fact, I'm teaching a sophomore course on design and implementation, and students have asked to see *my* solution to some of the assignments I've given (and yes, I *do* solve most of the problems, something that I find all too rare). The problem for me is that it is difficult to come up with assignments at this level, and I know that my solution would immediately find its way into every fraternity's archives (1/2 :-)), rendering it useless in the future. >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. I've tried this one, and I've been disappointed. Roughly speaking there are two types of students: those who have good designs (class G) and those who have bad designs (class B). Let's look at the possibilities at iteration 2: For students in class G, no further motivation to do a good job is necessary. No matter what they get, their predisposition to doing a good job will be reinforced. However, if given a bad product from stage one, they feel they are penalized (and given the short time spans for projects in a quarter or semester, they are right). The general reaction is "I did a good job, why do I have to work with this crap!" Those who can recover often end up doing two iterations: a rewrite of iteration 1 and whatever is required for iteration 2. Now consider students in class B. If given a good design from iteration one, they have a better shot at completing iteration 2, but the question remains whether they learned anything about their own substandard performance. In effect, this subidizes their poor work (we call it "hiding in the high grass" around here). On the other hand, if they are given a poor design, their demonstrably modest skills means they have a small chance of completing interation 2 on time. If I truly believed that all students in class B were inherently incapable of becoming productive, competent professionals, then the scenario above wouldn't bother me -- the good would pass, and the poor would fail. And no doubt many of those in class B shouldn't enter our profession, either because they lack the discipline or particular talents needed to succeed. But in my experience, there is a substantial subset of class B who just haven't caught on yet, and I don't want to flush them out. One approach I haven't tried is a "bidding" approach, where everyone's product from stage one is made available to the class. A small portion of the grade for iteration 2 would be tied to the number of people in the class who chose *your* solution as the basis for the next step. In this way, everyone sees a variety of designs, they get to choose the one they'll use next time, and the "recoverable" B students would choose someone else's G work simply to save their own necks. Has anyone tried something like this? Mike Lutz Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu