ejp@icd.ab.com (Ed Prochak) (07/16/90)
In article <18454@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F. Haugh II) writes: > In article <1990Jul11.233006.17884@nmt.edu> john@nmt.edu (John Shipman) writes: > >At New Mexico Tech, nobody gets a BS in CS without going > >through both the compiler class and the OS class; it's been > >this way for twenty years. And these aren't just lecture > >classes, either. Every student implements a whole compiler > >and a whole operating system from scratch, working in a team > >with one or two other students. > > At The University of New Orleans everyone was required to take > a theory course in languages, operating systems and so on, but > there were few, if any, courses where students were required > to actually write useful code. A suggestion to one of my > professors to implement a PL/1 compiler as a project for a > special studies course was met with incredible disinterest. > > Many universities that I am aware of take a dim view at students > working together on large projects. The fear being that the > students would cheat or slack off. The only course I had which > produced something "useful" was an advanced O/S course taught > by Jim "Nothead" Thomas. The course was excellent from a learning > experience, but a dismal failure as the O/S we wrote refused to > do much of anything. Jim Thomas can be found someplace in New > Mexico [ UNM I think ... ] working on Yet Another Degree. > -- > John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh > Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org > Proud Pilot of RS/6000 Serial #1472 At the University of Lowell, MA, the OS and Compiler courses are required core courses. The OS instructor did not require groups to work together, but he allowed it. (As it turned out my partner dropped the course, so I had to go it alone.) I also took the digital design Lab course which required project teams. We have a three person team and did very well in the course primarily, I think, because we did good team management. We worked well together, even though in the end not all of our hardware was finished (though everything that was finished worked). BTW, this was all for a Master's degree in Electrical Engineering with a concentration in Computer Engineering (Software option). Overall, it was a very good school, with some excellent evening instructors, and I think the program is getting even better. I really don't see why there is a problem in software courses with team projects. If there are also exams and other grading sourses within the same course (e.g. presentations, verbal exams), then at project completion, the instructor should have some idea of the ability of each student and how each may have contributed. In the Lab course, we had regular "status" meetings with the instructor where we described what we did so far, demonstrate it if possible, and get quizzed on various aspects. The OS course had midterm and final exams, and (if I recall correctly) the project teams were asked to do a little more than the single person teams. All reasonable requirements, I think. As an undergraduate in Physics labs, we often had to work with at least one partner. Other lab courses were that way too. Why not software?? (NOTE: other posters have pointed out schools with team project related courses in software. So the issue is why haven't the other curriculum's caught up??) (Pardon the inconvenience during our remodelling of the signature file) Edward J. Prochak (216)646-4663 I think. {cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com I think I am. Allen-Bradley Industrial Computer Div. Therefore, I AM! Highland Heights,OH 44143 I think? --- Moody Blues
reggie@dinsdale.paradyne.com (George W. Leach) (07/17/90)
In article <1522@abvax.UUCP> ejp@icd.ab.com (Ed Prochak) writes: >At the University of Lowell, MA, the OS and Compiler courses >are required core courses. The OS instructor did not require >groups to work together, but he allowed it. (As it turned out >my partner dropped the course, so I had to go it alone.) I >also took the digital design Lab course which required project >teams. We have a three person team and did very well in the course >primarily, I think, because we did good team management. We worked >well together, even though in the end not all of our hardware >was finished (though everything that was finished worked). During the initial CS courses that I took all work was done on an individual basis. I felt this was most appropriate, but once one has begun to become proficient at working on lab assignments there certainly is a great deal of benefit to learning how to work with others. Several junior and senior level courses required group projects. Perhaps the best one was a course where the group first had to come up with a project and write the requirements/specifications. After this portion of the project was graded the instructor took them back and redistributed them to other groups who then had to implement the project from the spec! Negotiations between the group who originated the spec and the group that implemented the project were encouraged. It was a great learning experience. BTW: I had been burnt on a number of group projects in the past due to one member either just not showing up or not pulling his/her weight. The group would receive a grade as a group, so the group was responsible. Having to deal with the situation can be very much like real life. [stuff deleted] >I really don't see why there is a problem in software courses >with team projects. If there are also exams and other grading >sourses within the same course (e.g. presentations, verbal exams), >then at project completion, the instructor should have some idea >of the ability of each student and how each may have contributed. Ah, but that would be more difficult for the instructor, wouldn't it? Remember all the discussions over the years about automatic grading programs, true/false and fill in the blank questions on tests versus problem solving? George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
dalamb@qucis.queensu.CA (David Lamb) (07/18/90)
In article <1990Jul17.120036.8944@pdn.paradyne.com> reggie@dinsdale.paradyne.com (George W. Leach) writes: > BTW: I had been burnt on a number of group projects in the past >due to one member either just not showing up or not pulling his/her >weight. The group would receive a grade as a group, so the group was >responsible. Having to deal with the situation can be very much like >real life. I've run a group project course 7 times; three or four times someone wasn't pulling their weight. I handled this by 1. having about 1/2 of the work be "individual responsibility" (a couple of short essays, plus some parts of group deliverables that could be clearly identified. For example, I asked that specs for modules be written by individuals) 2. Having about 10% of the grade be "group participation", which I judged by observation of group meetings, by "general impression", by reading the required weekly logs, and by "personnel reviews" from the other team members. 3. For really obvious screwups, where someone completely dropped out of producing a joint deliverable, I graded them with very low participation (0 in one case), plus graded the individiual as a separate "team" that failed to hand in the particular deliverable they missed. I've never failed anyone yet, though; my worst cases still contributed something worth a passing grade, but failed to pull their weight at some particular point. David Alex Lamb ARPA Internet: David.Lamb@cs.cmu.edu Department of Computing dalamb@qucis.queensu.ca and Information Science uucp: ...!utzoo!utcsri!qucis!dalamb Queen's University phone: (613) 545-6067 Kingston, Ontario, Canada K7L 3N6
john@nmt.edu (John Shipman) (07/20/90)
I am a great believer in confidential peer review. If you want to know whether someone did their share of the work, ask the other people on the team (in private). I don't think that someone on a successful team should get a good grade if that person didn't do a fair share of the work. In our software engineering course, we require that students write two papers a year, one at midterm and one at the end of the term, describing (among other things) the functioning of the team. We specifically instruct them to name names and give their opinion of how the others on their team did. Naturally, we tell them that their peers will not see the papers, so they don't have to worry about losing friends. The toughest situation is when a team failed because of one member, yet the others worked hard and did good work. Clearly, the offender should get a low grade. But should we also penalize the people that worked hard? I can think of arguments both for and against this. In industry, if a project fails, excuses are futile, because even though there was a ``good reason'' for the failure, you have still failed, and the marketplace is unforgiving. If the company is a start-up, one failure can be fatal. Yet, on the other hand, it is not fair to the hard-working students to penalize them for the actions of others on their team; it would tend to make those students bitter. I suppose it depends on how closely you want to simulate an industry environment. I think it is very important to get people in the habit of succeeding, especially people who are bound for industry. Therefore, I don't want people saying, ``it's okay that the project failed, because it's not my fault, it's because Clodworthy screwed up.'' In practice, when we have a situation where one team member is not contributing, we encourage the others to take up the slack, and reward them if they do so. In this situation, people can make a project work despite the failures of some members, and those who put in the extra effort will feel even more proud of their achievement than if everything went smoothly. -- John Shipman/Computer Science Department/New Mexico Tech/Socorro, NM 87801 (505)835-5301; john@jupiter.nmt.edu
karrer@sal-sun45.usc.edu (Anthony Karrer) (07/20/90)
Does anyone have suggestions for texts for group project classes, especially one for Seniors and emphasizes software engineering concepts. Take It Easy, Anthony Karrer (akarrer@pollux.usc.edu)
sadlerl@iuvax.cs.indiana.edu (LoriLee M Sadler) (07/20/90)
In article <1990Jul19.215334.28746@nmt.edu> john@nmt.edu (John Shipman) writes: >I am a great believer in confidential peer review. If you >want to know whether someone did their share of the work, >ask the other people on the team (in private). I don't >think that someone on a successful team should get a good >grade if that person didn't do a fair share of the work. > I agree. For group projects in my class, each student is assigned an individual grade based 80% on the final product and 20% on peer review. For the peer review, each student is asked to divide 100 points among group memebers, including him/herself. The students are able to freely distribute points as they see fit. I total the points for each person and then divide by the number of members in the group. It's amazing how accurate this system seems to be. On only one occasion was there significant disparity between the points one person in the group assigned himself and his team members and the points given by the rest of the group members. The students know up front that this is to be a part of their grade and I think that in itself encourages them to work well together.
dsims@uceng.UC.EDU (david l sims) (07/20/90)
sadlerl@iuvax.cs.indiana.edu (LoriLee M Sadler) writes: >For the peer review, each student is asked to divide 100 >points among group memebers, including him/herself. The students are able >to freely distribute points as they see fit. I total the points for each >person and then divide by the number of members in the group. There's something I don't understand here. If, say, a group has two people in it. Joe gives himself 50 points and his partner Mary 50 points. Likewise, Mary gives both herself and Joe 50 points, thus implying that both partners did an equal amount of work. Then the totals are: Joe 50 + 50 = 100 => 100 / 2 = 50 Mary 50 + 50 = 100 => 100 / 2 = 50 Does this result mean that both Joe and Mary receive a 50% grade for the peer review part of the course? Doesn't seem fair; what am I missing?
kolender@ics.uci.edu (Kurt Olender) (07/20/90)
>I am a great believer in confidential peer review. If you >want to know whether someone did their share of the work, >ask the other people on the team (in private). I don't >think that someone on a successful team should get a good >grade if that person didn't do a fair share of the work. At Colorado State, we've used a peer review form developed by a PhD in Industrial Psychology (who happened to be the wife of one of the instructors of the Software Engineering course) that is much like the sort of annual performance evaluation used in industry. We developed a simple mail-based method of having the students submit the forms and a simple AWK-based system to process the results. As long as the results are based relative to how people did within their own group and not tied to an absolute scale, we've found it worked fairly well and gave the students a taste of the way it runs in the "real world".
siegman@sierra.STANFORD.EDU (siegman) (07/20/90)
In article <1990Jul19.215334.28746@nmt.edu> john@nmt.edu (John Shipman) writes: > I can think of arguments both for and against this. > >In industry, if a project fails, excuses are futile, because >even though there was a ``good reason'' for the failure, you >have still failed, and the marketplace is unforgiving. If >the company is a start-up, one failure can be fatal. > >I think it is very important to get people in the habit of >succeeding, especially people who are bound for industry. I think you left out some of the other major arguments against this "success-oriented" or "only success is allowed" attitude. Like, if only success is allowed, then whatever outcome occurs will be called "success", whether it is or not. (People used to call this lying -- and lying to yourself, at that). The Air Force fosters a similar "only success is allowed" attitude as an institutionalized atitude among its officers. I read in the paper this morning that the aerospace company making the Stealth bomber has been cheating the Air Force, and making false progress reports and claims of success, for years. But no legal action can be taken against them, because it's clear that the Air Force knew it was going on and did nothing about it. Negative reports weren't wanted -- only successful ones. The Challenger launch was based on a success-oriented decision. If only success is allowed, business management will never get honest reports from lower down in the hierarchy. If the boss doesn't want to hear it, the troops sure won't pass the bad news along. Doesn't sound healthy to me. Remember that last consumer product you bought, that didn't work, or had egregious design and manufacturing flaws, should never have been on the market. Probably designed by a "success-oriented" engineering team, who had to meet a marketing deadline or else. Remember the Vietnam body counts. Success-oriented for sure. Obviously I'm going far beyond what Mr. Shipman said or, I'm sure, intended in his message, and I certainly don't mean to imply that he proposes or condones any of these abuses. I agree that it's important to get people to be success-oriented, or results-oriented, and from an early age. I agree that people should be motivated and rewarded for pitching in and making extra efforts to get the job done, and "make it work". But this "success-oriented" attitude can be (and has been) badly abused, and can lead to serious disasters. Not lying to yourself about the situation is enormously more important than being success-oriented -- and therefore should be rewarded (and very often isn't).
dalamb@qucis.queensu.CA (David Lamb) (07/20/90)
In article <1990Jul19.215334.28746@nmt.edu> john@nmt.edu (John Shipman) writes: >The toughest situation is when a team failed because of one >member, yet the others worked hard and did good work. >Clearly, the offender should get a low grade. But should we >also penalize the people that worked hard? I can think of >arguments both for and against this. In a school environment, where everyone seems so concerned about grades these days, you ought to do something to avoid hurting the people who worked hard. I have handled this in the past by 1. Having teams of 4-5 people and setting the workload to what I think 3-4 can do. 2. Have the students plan a series of subsets. This gives each team a fallback position. 3. Having a series of deliverables, such as user's guide and preliminary design. The team is less likely to fail, since you can detect poor performers earlier. 4. Once someone copped out on the last major deliverable (final running system), and the rest of the team found itself unable to deliver any working system. I examined their code far more carefully than I usually do, to see how far they were from working, so I could give them some sort of partial grade. I then graded the dropout as though he'd been a 1-person team that handed in the real team's deliverables, except getting a 0 on the last one. I then raised the real team's grade by a fraction that corresponded to the difference between the dropout's grade and the initial partial grade. I can't really justify point 4 except on fairly vague grounds, but the students all accepted it as reasonable. Taking into account the individual work, which wasn't hurt by the dropout, the team got roughly B+ grades overall when others were getting B+ or A-, so didn't get hurt too badly. The dropout got a C; he had contributed to all those other deliverables, so I didn't think I should fail him. All this presumes you're talking all-term team projects. If you're doing a whole bunch of different team assignments that don't build on each other in series, it should be possible to assign people to different teams for each assignment, and assign individual grades based on analysis of variance on the team grades. I haven't tried this; I'd be interested in comments. David Alex Lamb ARPA Internet: David.Lamb@cs.cmu.edu Department of Computing dalamb@qucis.queensu.ca and Information Science uucp: ...!utzoo!utcsri!qucis!dalamb Queen's University phone: (613) 545-6067 Kingston, Ontario, Canada K7L 3N6
sadlerl@iuvax.cs.indiana.edu (LoriLee M Sadler) (07/21/90)
In article <5556@uceng.UC.EDU> dsims@uceng.UC.EDU (david l sims) writes: >sadlerl@iuvax.cs.indiana.edu (LoriLee M Sadler) writes: > >>For the peer review, each student is asked to divide 100 >>points among group memebers, including him/herself. The students are able >>to freely distribute points as they see fit. I total the points for each >>person and then divide by the number of members in the group. > I apologize for the confusion here, which is totally my fault. My procedure should have read: I total the points for each person and then multiply those points by the weight given to the peer review component. So, if a group received 90/100 points on their final product, which is weighted at 80% of the total project grade, they would have 72 percentage points for their product portion. Then I consider the peer reviews: MaryBeth Steven Bob 50 25 25 50 25 25 40 30 30 -- -- -- 140 80 80 *.2 *.2 *.2 --- --- --- .28 .16 .16 <--- weighted peer review + + + .72 .72 .72 <--- product percentage --- --- --- 100% 88% 88% <--- final project grade -LoriLee
ejp@icd.ab.com (Ed Prochak) (07/25/90)
In article <1990Jul17.120036.8944@pdn.paradyne.com>, reggie@dinsdale.paradyne.com (George W. Leach) writes: [stuff deleted] > Several junior and senior level courses required group projects. > Perhaps the best one was a course where the group first had to come up > with a project and write the requirements/specifications. After this > portion of the project was graded the instructor took them back and > redistributed them to other groups who then had to implement the project > from the spec! Negotiations between the group who originated the spec > and the group that implemented the project were encouraged. It was a > great learning experience. > > > BTW: I had been burnt on a number of group projects in the past > due to one member either just not showing up or not pulling his/her > weight. The group would receive a grade as a group, so the group was > responsible. Having to deal with the situation can be very much like > real life. In the same lab course I mentioned there was a second group. (about 5 people in their group vs. 3 in ours) They decided to go the safe route and do the traditional microcoded microprocessor. Somewhere along the way, they lost sight of the goal. For example, one evening as our group was getting code prepared for burning proms, they were all excited about getting their reset circuit working. I mean that was all they had on the board was just a reset circuit!! At the end of the semester, they still had very little built. They got an incomplete. (And we were scared that we would get a bad grade because we didn'd finish the second half of our project. With the instructor's help that last day of class, we found out why we could not communicate with the graphics chip. Still, we got a lot completed and working at that point.) > > [stuff deleted] > > >I really don't see why there is a problem in software courses > >with team projects. If there are also exams and other grading > >sourses within the same course (e.g. presentations, verbal exams), > >then at project completion, the instructor should have some idea > >of the ability of each student and how each may have contributed. > > Ah, but that would be more difficult for the instructor, wouldn't > it? Remember all the discussions over the years about automatic grading > programs, true/false and fill in the blank questions on tests versus > problem solving? > > George W. Leach AT&T Paradyne > (uunet|att)!pdn!reggie Mail stop LG-133 > Phone: 1-813-530-2376 P.O. Box 2826 > FAX: 1-813-530-8224 Largo, FL 34649-2826 USA yea, I remember automatic grading, etc. Still, That's just an excuse for avoiding thorough evaluations. And I haven't seen too many software courses that used fill-in-the-blank style tests. It is probably more prevalent to have automatic grading in the Social science classes nowadays?? (my undergraduate degree was 1976, so my view is somewhat dated). But George, we do agree that it can be done. Edward J. Prochak Voice: work-(216)646-4663 home-(216)349-1821 Email: {cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com USmail: Allen-Bradley, 747 Alpha Drive, Highland Heights,OH 44143 Wellington: ENGINEERING is "the ability to do for one dollar, what any damn fool can do for two."
anand@wotan.top.cis.syr.edu (Rangachari Anand) (04/30/91)
It is end of the semester and I have been hearing a number of gripes from students regarding group projects. As always, one enthusiastic person in the group does 90% of the design and programming. Not surprisingly, this leads to resentment on the part of the enthusiastic person: "Why should my work help these free-loaders get a good grade?". While it is true that the intent of group projects is to prepare students for the real world, the students are, it would seem, expected to pick up the techniques of group interaction on their own. Is there any book containing practical tips for solving this problem which I could recommend to my students? R. Anand | School of Computer and Information Science anand@top.cis.syr.edu | Syracuse University.
g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) (05/02/91)
In article <1991Apr29.212148.15481@rodan.acs.syr.edu>, anand@wotan.top.cis.syr.edu (Rangachari Anand) writes: > It is end of the semester and I have been hearing a number of gripes > from students regarding group projects. As always, one enthusiastic > person in the group does 90% of the design and programming. Not > surprisingly, this leads to resentment on the part of the enthusiastic > person: "Why should my work help these free-loaders get a good grade?". This has become an age-old question. I do group projects in my CS2 and Software Engineering courses. > While it is true that the intent of group projects is to prepare > students for the real world, the students are, it would seem, expected > to pick up the techniques of group interaction on their own. Is there any > book containing practical tips for solving this problem which I could > recommend to my students? I do the following: 1) use a text book that stresses team psychology and interaction. 2) spend at least two class hours lecturing on team work (this may be one of the most important and significant set of lectures you can ever give). 3) make the instructor the "project manager." 4) have the team choose their own leader. 5) provide communication opportunities for the students (mail, talk, phone, etc.) 6) require weekly writen reports on the progress to their goal(s). 7) grade using a biased technique: I have the students RANK themselves in the team according to the amount of critical effort they contributed; have them SIGN such a report from the team; choose a team grade and distribute that grade according to the rankings. For example... if they rank themselves, 1, 2, and 3 and the team grade is 80% then the grades are 90%, 80%, and 70%. This method seems to work well. I am convinced that the instructor can't just give a team project and remain passive. > R. Anand | School of Computer and Information Science > anand@top.cis.syr.edu | Syracuse University. -- George C. Harrison ----------------------- ----- Professor of Computer Science ----------------------- ----- Norfolk State University ----------------------- ----- 2401 Corprew Avenue, Norfolk, Virginia 23504 ----------------------- ----- INTERNET: g_harrison@vger.nsu.edu ---------------------------------
jlong@uhunix1.uhcc.Hawaii.Edu (John Long) (05/03/91)
In article <1991Apr29.212148.15481@rodan.acs.syr.edu> anand@top.cis.syr.edu (Rangachari Anand) writes: >................deleted >While it is true that the intent of group projects is to prepare >students for the real world, the students are, it would seem, expected >to pick up the techniques of group interaction on their own. Ouch! You hit a nerve... Last semester I took a course in system analysis which consisted of some lectures on theory and one group project for the class of 7 students. I do not feel that it prepared me *at all* for the so called real world. Let me say that I am an older student (43), have been involved with computing for about 10 years, and have taught computer literacy in high school. So I know a little about group projects and the real world. The problem was that it was a group of peers. The blind leading the blind. In the real world, groups are structured, with an experienced leader. The flip side of the "one-person-does-all-the-work" problem is the case where one person dominates the group. This was what happened in our group (it wasn't me! ;-) The instructor would give new job assignments or titles to the various members of the group every few weeks, but basically we were each doing our own thing, because we had no real leadership. As a result, I jumped ship when I couldn't convince the group that we were headed for trouble by ignoring a certian aspect of the problem. I do that in the real world, too! I recommend that if you give a group project, you should be an active member of the group, or possibly incorporate another more advanced class into the group, so that there is some sort of leadership recognized by the members. In other words, *teach* group activity, don't just assign it. In the real world, there is corruption, incompetence, and all sorts of b.s. I don't see the value of a course which gives hands-on experience with it. But, then again, maybe it would be... You've asked a very good question! I hope some others can provide some more feedback. Aloha, LongJohn
g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) (05/05/91)
In article <12806@uhccux.uhcc.Hawaii.Edu>, jlong@uhunix1.uhcc.Hawaii.Edu (John Long) writes: > In article <1991Apr29.212148.15481@rodan.acs.syr.edu> anand@top.cis.syr.edu (Rangachari Anand) writes: > >>................deleted >>While it is true that the intent of group projects is to prepare >>students for the real world, the students are, it would seem, expected >>to pick up the techniques of group interaction on their own. > > Ouch! You hit a nerve... Last semester I took a course in system analysis > which consisted of some lectures on theory and one group project for the > class of 7 students. I do not feel that it prepared me *at all* for the > so called real world. > > The instructor would give new job assignments or titles to the various members > of the group every few weeks, but basically we were each doing our own thing, > because we had no real leadership. As a result, I jumped ship when I couldn't > convince the group that we were headed for trouble by ignoring a certian > aspect of the problem. I do that in the real world, too! Did you EVER speak to the instructor about this?? > I recommend that if you give a group project, you should be an active member > of the group, or possibly incorporate another more advanced class into the > group, so that there is some sort of leadership recognized by the members. > In other words, *teach* group activity, don't just assign it. The instructor MUST act as the project manager. A team of totally unexperienced students will almost certainly fail to meet the minimum requirements for ht project. > In the real world, there is corruption, incompetence, and all sorts of b.s. > I don't see the value of a course which gives hands-on experience with it. > But, then again, maybe it would be... It is of real value if taught correctly. I have taught several courses over the past five years with large group projects (with requirements specifications, designs, source code, users' manual, testing documents, configuration management, quality control, etc....) to undergraduates. I have received several post-graduate responses that the course was extremely valuable. Here are some "Fundamental Truths of Teaching Software Engineering" that I use: 1: Have the students keep a LOG of EVERYTHING they do in the course. 2: Never lecture more than two hours a week (like a 3-credit 2/lecture - 2/lab course). 3: Require the student team to hand in a final report RANKING their each individual's effort relative to the rest of the team. Have them all sign it. 4: Encourage the students to report IMMEDIATELY any problems they are having. 5: loop PUT_LINE("Stick to a Schedule"); end loop; 6: The instructor must assume the role of project manager. S/he must also be available at STRANGE times to answer question (weekends, nights, etc.) via mail, etc. 7: The instructor needs to read, read, and read several software engineering books. (I've found that it really doesn't matter if the students have a book or not.) 8: Lecture for at least a week (perhaps two) on team organization, group psychology (perhaps some of the most important computer science lectures you'll ever give). 9: Don't require the students to program in a nonfamilar language. 10: Remember that the students have other courses. Don't require them to develop software you can't do in a 40-hour week. 11: Use COCOMO or some other appropriate cost metric for a "reality check." 12: Toss out all old notes. They are a crutch. Trust your experiences and recent readings. The above lessons were learned from past errors and not from any native feelings. George... -- George C. Harrison ----------------------- ----- Professor of Computer Science ----------------------- ----- Norfolk State University ----------------------- ----- 2401 Corprew Avenue, Norfolk, Virginia 23504 ----------------------- ----- INTERNET: g_harrison@vger.nsu.edu ---------------------------------