warren@psu-cs.UUCP (Warren Harrison) (03/18/88)
The recent discussion in this newsgroup regarding the poor quality of software engineering in the US today is quite interesting. Before we end up gnashing all our teeth into stubs, I'd like to point out that hardly an automaker has yet to have at least one model recalled due to faulty brakes or whatever. This will no doubt become more and more common as mechanical systems begin to become more and more complex (I can't think of a single mechanical system today which is anywhere close to as complex as even a moderate sized compiler, much less an operating system or C3 system). Perhaps what is most amusing is the universal agreement that "management" (whoever they are) is to blame. The general feeling seems to be that if only managers would let us programmers have our head, everything would be right with the world. In the first issue of American Programmer (a new magazine that Ed Yourdon is publishing out of his Mac II and office in NY) this issue is dealt with as frankly as I have seen so far. Yourdon points out that the average programmer isn't all that great anyway, and should share at least part of the blame. This is no doubt due to the great influx of people who wanted secure, high paying jobs in the early 1980's, but who really weren't cut out for writing software (I must have taught 500 of them from 1979 to 1984, at various universities from Missouri to Oregon). While I agree that management must share the blame on the general state of things, we (ie, programmers) have to bear some of the burden. Almost every company I have seen represented in this newsgroup has had at least one major fiasco (publicized or not). There is lots more to do with this topic in the American Programmer. For more info about Ed's new venture, write him at: 161 West 86th Street New York City, NY 10024-3434 this new magazine is by far one of the best I've yet to see, and I suggest everyone interested in the state of the American Programmer look into it! (I am not affiliated in any way with Ed Yourdon, Yourdon Press, Children's Software [the ones that publish AP], or anything else east of the Oregon-Idaho state line). Warren Harrison The University of Portland Portland, OR 97203-5798
msir_ltd@ur-tut (Mark Sirota) (03/20/88)
In article <555@psu-cs.UUCP> warren@psu-cs.UUCP (Warren Harrison) writes: > Perhaps what is most amusing is the universal agreement that "management" > (whoever they are) is to blame. ... Yourdon points out that the average > programmer isn't all that great anyway, and should share at least part of > the blame. This is no doubt due to the great influx of people who wanted > secure, high paying jobs in the early 1980's, but who really weren't cut > out for writing software (I must have taught 500 of them from 1979 to > 1984, at various universities from Missouri to Oregon). > > While I agree that management must share the blame on the general state of > things, we (ie, programmers) have to bear some of the burden. I dunno who's been saying that it's management's fault, I fully disagree. There are far too many bad programmers out there. Some of them are really bad. I've had to work UNDER some of them, since I only work summers. Some of the software you see out there boggles the mind - how many times have you said, "God, I would never have released anything like that!" Of course, part of the problem may be that I consider myself a good programmer - and so does everyone else. It's hard for non-programmers to tell who's better. In that respect, it is management's fault. They're the ones doing the hiring... -- Mark Sirota msir_ltd%tut.cc.rochester.edu@cs.rochester.edu (rochester!ur-tut!msir_ltd)
rmac@well.UUCP (Robert J. McIlree) (03/20/88)
In article <555@psu-cs.UUCP> warren@psu-cs.UUCP (Warren Harrison) writes: > >Perhaps what is most amusing is the universal agreement that "management" >(whoever they are) is to blame. The general feeling seems to be that if >only managers would let us programmers have our head, everything would be >right with the world. In the first issue of American Programmer (a new >magazine that Ed Yourdon is publishing out of his Mac II and office in NY) >this issue is dealt with as frankly as I have seen so far. Yourdon points >out that the average programmer isn't all that great anyway, and should >share at least part of the blame. This is no doubt due to the great influx >of people who wanted secure, high paying jobs in the early 1980's, but who >really weren't cut out for writing software (I must have taught 500 of them >from 1979 to 1984, at various universities from Missouri to Oregon). > No argument that programmers should share part of the blame for failures. I think the majority of blame *does* lie with management, though. Realize that software projects are, more often than not, political ventures as opposed to technical ones. Programmers, like all other employees, need *direction and guidance* at various intervals. Who is to provide that? Large software projects need organization, planning, and expertise in various capacities to come out right. The programmer is only part of the solution. What do we have in a project besides programmers and managers? System test people, technical support (both internal and external), documentation/tech writing, secretaries, clerks, and system engineers immediately come to mind. Examining what went wrong on a particular project involves more than looking at the bugs and inadequacies in delivered software. Defects must (and can) be traced to various phases of the software lifecycle that programmers have little to do with! Like requirements definition, test plans, effective management and leadership of the project team, and so on. As to the 500 or so people you mention that weren't cut out for writing software, how many were writing software after they graduated? I'd take a guess that a good number of them went to positions similar to those mentioned above. What formal instruction did they receive at their institution to prepare them for a software QA, system engineering, tech writing, or tech support job? Did the CS departments in which you were affiliated with even approach these subjects? Or is it left to those one-day to one week seminar courses employers pay for to turn BSCS grads into one week wonders of system test? To summarize, programmers represent a portion of the solution in delivering high quality software systems on-time and within budget. They, like any other resource, are controlled by managers. When placing the blame on project failure, one must also analyze the other components of the solution, the other groups involved in that effort, and their management. You'd be surpsised at how many failures *do not* involve the prgrammers. Bob McIlree (ihnp4, lll-crg}well!rmac
shap@bunker.UUCP (Joseph D. Shapiro) (03/22/88)
In article <555@psu-cs.UUCP> warren@psu-cs.UUCP (Warren Harrison) writes: > Perhaps what is most amusing is the universal agreement that "management" > (whoever they are) is to blame. ... Yourdon points out that the average > > While I agree that management must share the blame on the general state of > things, we (ie, programmers) have to bear some of the burden. I think that one of the many ways that programmers must improve is in standing up and saying NO to unreasonable expectations on the part of management. If management says "I need this in X weeks", but you know it can only be done in 3*X weeks, or maybe you can glue something together in X weeks if you work nights and weekends, what can you do? a) work nights and weekends. This might get you in good with the boss. Your boss may not even realize that you are doing something out of the ordinary. It is likely that management will expect the same sort of productivity when they set the next deadline. Also consider that such efforts often leave some things "to clean up later", but that you seldom get the luxury of going back and cleaning them up. This is can lead to a most vicious circle. b) be willing to take a little heat and explain to management exactly how long it will take to do the job right and WHY. c) work extra hours but make damned sure that management understands how much work is being done AND WHAT IT COSTS THEM both in terms of overtime or burn-out, and in terms of lower quality in the resulting product. I seems that too many programmers are more willing to do (A) than (B). (C) would seem to be the best of both worlds, but is actually a double negative to most programmers -- "I gotta work late AND talk to management?" BTW, I was a programmer (still am under the skin) and am now a manager, so I feel that I can see both sides. -- -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Joe Shapiro "My other car is a turbo... Bunker Ramo Olivetti too." {decvax,yale,philabs,oliveb}!bunker!shap
shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (03/22/88)
In article <3415@bunker.UUCP> shap@clunker.UUCP (Joseph D. Shapiro) writes: >If management says "I need this in X weeks", but you know it can only >be done in 3*X weeks, or maybe you can glue something together in X >weeks if you work nights and weekends, what can you do? > >a) work nights and weekends. [...] > >b) be willing to take a little heat and explain to management exactly >how long it will take to do the job right and WHY. > >c) work extra hours but make damned sure that management understands >how much work is being done [...] > >It seems that too many programmers are more willing to do (A) than (B). One reason I've observed is hubris - programmers have heard all about "Real Programmers" and imagine themselves either to be such, or they aspire to the position. Given such feelings, it's very easy for managers to manipulate the programmers - "What, you can't do all that on time? Old Joe Fortran would write the whole thing in two days!". Of course, the programmers get indignant and insist they're just as good as Joe Fortran, but without stopping to consider that Joe Fortran (now departed for greener pastures) was also the person who wrote such disastrous code that millions are now being spent to keep up with the continual stream of bugs. The managers' comments also have a vague air of threat - "If you can't do the job, we'll replace you with somebody who can," in case any of the programmers have resisted the appeal to their egos. Schools are part of the problem, since it has become habitual to assign students to write massive amounts of code as weekly exercises. Of course, (ahem) I've never made up such an assignment. :-) Needless to say, the best grades go to the students who hack the fastest, and I get howls of complaint (not just from students!) for counting off on "minor" bugs or (heaven forfend!) style. Trying to teach better programming practices is definitely an uphill battle... stan shebs shebs@cs.utah.edu
UH2@PSUVM.BITNET (Lee Sailer) (03/23/88)
In article <5359@utah-cs.UUCP>, shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) says: > >Schools are part of the problem, since it has become habitual to assign >students to write massive amounts of code as weekly exercises. Of course, >(ahem) I've never made up such an assignment. :-) Needless to say, the I have been trying to make this point here. Imagine this freshman programming course---start with data flow diagrams, strucutre charts, and walk-throughs--- add egoless programming---teach symbolic debuggers and syntax directed editors from day one. Sure, you might hate some of these techniques. But the point is that we need to teach professional skills from day one, sort of like chemistry teaches basic lab skills in freshman chemistry. Just a thought. Flame away...
shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (03/24/88)
In article <36845UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >[...] Imagine this freshman programming >course---start with data flow diagrams, strucutre charts, and walk-throughs--- >add egoless programming---teach symbolic debuggers and syntax directed editors >from day one. Sounds good to me... The main objection that comes to mind is the increased volume of material. If you go to a simpler language like Scheme (flame flame) then you would have to spend less time on random syntax and semantics. Another thought that comes to mind is that courses of study in many disciplines are extremely long, lasting perhaps several years before the students are ready to do things on their own (think about when EEs do their first nontrivial circuit designs). In CS, it seems to be assumed that one intro course and one data structures course makes an educated programmer, and everything after that can be electives. On the other hand, while I "know" that students should understand the theory of sorted algebras before writing an abstract data type, I don't "feel" that so much theory is essential to training professional software engineers. A dilemma... stan shebs shebs@cs.utah.edu
raveling@vaxa.isi.edu (Paul Raveling) (03/24/88)
In article <3415@bunker.UUCP> shap@clunker.UUCP (Joseph D. Shapiro) writes: > >I think that one of the many ways that programmers must improve is in >standing up and saying NO to unreasonable expectations on the part of >management. > >If management says "I need this in X weeks", but you know it can only >be done in 3*X weeks, ... A variant of this is the occasional management decision to simply throw more people at a problem. In software, as in real life, there are projects that can't be accelerated this way. Nine women can't necessarily do in one month what one woman can do in nine. --------------------- Paul Raveling Raveling@vaxa.isi.edu
dtraver@macomw.ARPA (George Andrew Traver) (03/25/88)
>In article <36845UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: > >[...] Imagine this freshman programming >course---start with data flow diagrams, strucutre charts, and walk-throughs--- >add egoless programming---teach symbolic debuggers and syntax directed editors >from day one. > I graduated from UCSD with a CS degree. The problem I found with my education was that problem solving techniques were never covered in depth. My first two years of work I impressed everyone I worked for except myself. My code was not clean and did not always flow logicaly. But it always met or exceeded functional requirments. Just lately I've been working with some PHD people with tons of experience and I fell I'm just now starting to learn how to code. The reason this problem exist in school is because it would take a lot of time to realy understand each program turned in and grade them on there logical flow. This is why prof's wont do it. The TA's who grad the programs are just as porly trained as the students. The whole grade is placed on comments and correct output. Well thats no problem for me, I've done it in the past for employers. I've handed them well commented programs that run correctly but I would hate to be someone else who had to modify it. ******************************************************************************* Success has many fathers :-), while failure is an orphan. :-( ------------------------------------------------------------------------------ The views expressed in this article are shared by no other living being or organization I know of. ( especialy my girlfreind ) dtraver@macomw.arpa FLAMES > /dev/null *******************************************************************************
lishka@uwslh.UUCP (Christopher Lishka) (03/25/88)
I too think that this is a great idea. All too often the real
skills in programming are left aside in favor of theory, and theory
does not necessarily a good programmer make. As a current
undergraduate who has learned most of his real "skills" from my
current job (from an excellent, well-versed programmer who also works
here), I am now amazed that what I thought were good programming
skills (i.e. knowing all of the commands of a language, etc.) are only
a small part of a much wider base.
One problem I see, however, is that there really isn't much of a
standard OS to work from in teaching the practical aspects of
programming. For instance, where I work I use tools such as
Gnu-Emacs, several C compilers, Perl, Yacc, Lex, Ksh, Csh, Sh, RCS,
Gprof, Dbx, etc. all running on 4.3BSD Unix. Now, at school I have
used such a wide variety of systems (from Xerox InterLisp workstations
to archaic local OS's) that the vast array of tools can be
overwhelming, especially when they are written to work with systems
that differ in *philosophy* as well as implementation. A structured
Lisp editor is not like Vi. An interpretive Lisp environment can be
much different from, say, the edit-compile-run-edit cycle so typical
of many C projects. Using RCS can be much different than saving
backup directories as well as using Tar with a 9-track tape drive.
There is a lot of "theory" involved in organizing programs as well as
modifying and writing them, and it is this kind of theory that seems
to be left to the student to discover.
Maybe there should be a course on this sort of thing. I think a
mandatory course titled something like "Program Writing" should be
offered (at least at this University) where issues such as programming
environments and project management should be discussed. At very
least it could give the prospective CS undergraduate major a set of
"rules" or "guidelines" to go about organizing and writing a general
program. This course could be a 2nd or 3rd course, after a standard
language or two has been taught, so that something well known like
Pascal, Scheme, or whatever can be assumed to be already known, in
order to focus on program writing styles independent of any language.
Well, those are just a few thoughts. Any comments or criticisms?
-Chris
--
Chris Lishka /lishka@uwslh.uucp
Wisconsin State Lab of Hygiene <-lishka%uwslh.uucp@rsch.wisc.edu
"My cockatiels control my mind!"\{seismo, harvard,topaz,...}!uwvax!uwslh!lishkawarren@psu-cs.UUCP (Warren Harrison) (03/25/88)
> > Sure, you might hate some of these techniques. But the point is that we > need to teach professional skills from day one, sort of like chemistry > teaches basic lab skills in freshman chemistry. > > Just a thought. Flame away... This is a very good suggestion. However, here is my problem ... how do you justify to a student that a program to compute the sum of a list of numbers uses a procedure? Or a Warnier Orr (or data flow) diagram? I guess I'm saying that my experience leads me to believe that the tools have to be motivated by something other than saying "... it's good for you ...". At the intro level it gets really hard (for me) to motivate the use of such tools. Even something as simple as commenting is difficult to justify for a three or four line program. On the other hand, maybe my examples and assignments are overly] simple compared to those of the rest of you. One approach that I have found to work quite well however is in the COBOL programming course. The first few programs involve the (extensive) modification of a working program of several hundred lines of code. The students really appreciate the existence of comments and meaningful variable names then. Also, the program tends to serve as an exa example of the type of commenting and style I expect from the students' programs I'd like to hear the approach others take to this problem ... do most people simply mandate the use of tools like DFD's and modularity, or do you provide motivation (besides saying you'll be glad you did it this way next semester)? Also, does anyone address th eissue of program maintenance in their classes by having students modify a non-trivial program? It is ironic that so little attention is paid to maintenance in school when the majority of graduates start off in this activity. Warren Harrison The University of Portland
pase@ogcvax.UUCP (Douglas M. Pase) (03/25/88)
In article <36845UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >[...] Imagine this freshman programming >course---start with data flow diagrams, structure charts, and walk-throughs--- >add egoless programming---teach symbolic debuggers and syntax directed editors >from day one. This sounds like it might be a reasonable idea. There is, however, at least one difficulty which must be overcome. Walk throughs and egoless programming are targeted for large, multi-person projects. Beginning course assignments generally need to be geared towards small, single person programs. My own personal opinion is that the earliest courses need to familiarize students with the machine, languages, and tools. Many freshmen still think of computers as black boxes where wonderous things are done by magic. Structured programming can certainly be taught to students at this level. Flow diagrams, structure charts, and symbolic debuggers are all appropriate here. Syntax directed editors are a two-edged sword and might be saved for later. Once they become familiar with the nature of the computer -- they see what a language is, they understand how programs work -- teach them hard core software engineering, and insist they use it! I know you all have been asking for my opinion on this, and there, at last, you have it! -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)
UH2@PSUVM.BITNET (Lee Sailer) (03/26/88)
In article <5367@utah-cs.UUCP>, shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) says: > >In article <36845UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: > >>[...] Imagine this freshman programming >>course---start with data flow diagrams, strucutre charts, and walk-throughs--- >>add egoless programming---teach symbolic debuggers and syntax directed editors >>from day one. > >Sounds good to me... The main objection that comes to mind is the increased >volume of material. At first, it sounds like *more* material, but look what it might mean (if it worked): By spending two weeks up front, teaching them to use a symbolic debugger, they'd save 5 hours per week for the rest of the term because they would be faster debuggers, for a net gain of about 60 hours. During this 60 hours, they can learn about lots of other keen stuff 8-)
smith@cos.com (Steve Smith) (03/26/88)
In article <312@uwslh.UUCP> lishka@uwslh.UUCP (Christopher Lishka) writes: > Maybe there should be a course on this sort of thing. I think a >mandatory course titled something like "Program Writing" should be >offered (at least at this University) where issues such as programming >environments and project management should be discussed. At very >least it could give the prospective CS undergraduate major a set of >"rules" or "guidelines" to go about organizing and writing a general >program. This course could be a 2nd or 3rd course, after a standard >language or two has been taught, so that something well known like >Pascal, Scheme, or whatever can be assumed to be already known, in >order to focus on program writing styles independent of any language. > Well, those are just a few thoughts. Any comments or criticisms? > > -Chris It sounds like a great idea to me. Doing it properly may be a problem, however. Two of the main characteristics of commercial programs are (1) they tend to be big, worked on by a group rather than by one person, and (2) they are designed to last a long time, with upgrades along the way. This type of environment is *very* difficult to simulate. Simply attending lectures and reading books is no substitute for being given a huge, greasy mass of ten year old spaghetti code and being told "Add these ten simple features. You've got three weeks." After taking the course, you know about modular design, documentation, and testability in your head. After untangling that spaghetti, you'll know it in your stomach. On a smaller scale, I've found the venerable "Software Tools" to be an excellent guide to the how and (more importantly) why of small program writing. Unfortunately, I don't know anything nearly as good that addresses larger system development. -- -- Steve (smith@cos.com) ({uunet sundc decuac hqda-ai hadron}!cos!smith) "Truth is stranger than fiction because fiction has to make sense."
mjl@ritcv.UUCP (Mike Lutz) (03/28/88)
In article <36845UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: > >I have been trying to make this point here. Imagine this freshman programming >course---start with data flow diagrams, strucutre charts, and walk-throughs--- >add egoless programming--- Problem: it's awfully hard to motivate freshmen (or anyone else who hasn't worked on large programming projects) of the importance of these techniques (or even what the techniques really mean). They have know experience base to fall back on; no examples to provide a context for understanding any of this. Or, as a colleague once said "We try to expose students to all of these important concepts, only to find that most of them are immune." >teach symbolic debuggers and syntax directed editors >from day one. No! no! no! If you want anyone to learn the discipline of program design, then the *last* thing you want them to have is a fancy debugging environment. That is, unless your idea of modern programming practice is to spend most of your time debugging sloppily conceived code. Make debugging easy and attractive, and I guarantee that's the message you'll send the next generation of CS grads! I'm in full agreement with Harlan Mills here - we definitely need better tools, but interactive debuggers are not in this class. Mike Lutz -- Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {allegra,seismo}!rochester!ritcv!mjl CSNET: mjl%rit@csnet-relay.ARPA
karenc@amadeus.TEK.COM (Karen Cate;6291502;92-734;LP=A;60kC) (03/29/88)
At this point in the discussion, I think I'll add my $.02 worth. This
discussion has sort of meandered to an educational sidetrack, but so
many educators read this group, that I wanted to keep it going here.
After all, you don't HAVE to read it...
I have now been out of college for 1 year. I graduated in CS from
Oregon State University - whose CS dept was in a constant state of
flux the entire time I was there. (No flames, please, that was only
an opinion -- I think it's better now.) Anyway, there are some out-
standing individuals there who had some good ideas. Here is a list
of things I felt helped me the most:
1. Internships: First and foremost. I wish everyone could have the
wonderful and varied experiences I had. 90% of what was presented
to me in class would have been useless (misunderstood) if I hadn't
already been in the "real world" -- at least the world I wanted to
work in. I'm not kidding here. Never in school did I do anything
vast enough to really justify real design work (Warnier Orr diagrams,
or other design documentation techniques). Since I had already
done a project that these would have been a tremendous help, I
understood it.
A reasonable alternative: We had an "Applications Programming"
class. It was a two term sequence in which the students solved
a real world problem for someone. The nature of the class changed
from term to term, but because it was two entire quarters devoted
to one programming project, it could be large and thorough.
2. One teacher had us write a program and hand it in. He then randomly
distributed them back to the class. We then had to add/modify this
other students' program. This was the second CS class we took, so
we: a) learned a whole lot, and b) none of ours was good enough that
we took offence at the comments of our peers (as a general rule).
There was not one complaint about requiring comments after that.
It also taught us the difference between helpful comments and the
stuff you put in to please the TA.
3. Someone has already mentioned modifying an existing piece of code.
This is a wonderful technique. Especially with a language like
COBOL, and especially if the students already know another language.
After they've dealt with a well written program. Give them a
poorly written one without comments. [My second internship was to
modify (re-write) a program that was written in basic by a non-
programmer EE (I don't mean to say that EE's can't program, just that
this individual was not particularly adept). Then it was ported
three times through three different basics. Gads what a nightmare!]
4. Try being a grader. I spent many long nights grading lousy COBOL
code. It taught me a LOT. I feel kind-of sorry for whoever
hired some of those students, they would have to do a lot of re-
training. It made my experiences all the more meaningful.
I have some other miscellaneous comments:
- We changed computers/OS's virtually every class. This was good and
bad. Bad: The teachers were also changing often, and knew nothing
about the machines we were working on (They had a vax they used...).
Whatever documentation came with <pick-yer-box> was not available
for anyone to use. We spent many precious hours fighting syntax
problems. Good: We graduated with a diverse experience base. We
may not have known a lot about any individual, but we knew enough
to get ourselves in trouble. Give us a manual and we could be
dangerous!
- I strongly feel that there should be a "program" at any given school.
Instead of having a bunch of classes, some of which are required.
There should be a continuous thread of classes where the curriculum
is set for the whole four years. Hopefully, you should not have to
fight to get into these. No, they shouldn't all be taught by the
same instructor, but SOME projects should be the same, and each
student should be at about the same place at the same time. Then
you could pick up a program that was written a couple of months
ago, etc. The theory can be developed in stages, instead of all
in your junior or senior year. Then students could customize their
programs with their choice of electives. I could write pages on
how I would do it... But, then again, what do I know?
Ok. I'll give up now. Remember, this is all my opinion, and I'm
not sure that I claim it. Don't blame Tek or OSU for any of this.
Karen Cate
tektronix!amadeus!karenc -OR- karenc@amadeus.LA.TEK.COMdaveb@geac.UUCP (David Collier-Brown) (03/29/88)
The University of Toronto does/did a course on software engineering where teams of students add features to each other's programs, which they have to buy (using marks from a previous assignment for dollars, of course) --dave (I went to UofW, fortunatly) c-b
jetzer@studsys.mu.edu (jetzer) (03/29/88)
In article <1232@cos.com>, smith@cos.com (Steve Smith) writes: > In article <312@uwslh.UUCP> lishka@uwslh.UUCP (Christopher Lishka) writes: > > > Maybe there should be a course on this sort of thing. I think a > >mandatory course titled something like "Program Writing" should be > >offered (at least at this University) where issues such as programming > >environments and project management should be discussed. At very > >least it could give the prospective CS undergraduate major a set of > >"rules" or "guidelines" to go about organizing and writing a general > >program. This course could be a 2nd or 3rd course, after a standard > >language or two has been taught, so that something well known like > >Pascal, Scheme, or whatever can be assumed to be already known, in > >order to focus on program writing styles independent of any language. > > > It sounds like a great idea to me. Doing it properly may be a problem, > however. Two of the main characteristics of commercial programs are (1) > they tend to be big, worked on by a group rather than by one person, and > (2) they are designed to last a long time, with upgrades along the way. > This type of environment is *very* difficult to simulate. > Marquette University offers a course much like the one discussed above. It's a one semester, one credit class that compsci majors take right after Intro to Structured Programming in Pascal. Each semester a 'typical real-world' program is selected; the semester that I took the course, it was to keep track of a database of magazine addresses and expiration dates. My (heavily commented) source code was about 2400 lines long; this may or may not seem long to professional programmers, but it's a far cry from the < 200 line programs that are typically assigned in the intro to pascal course. Emphasis is placed on making sure the program is easy to maintain and program modularity. (Even to day I pull out certain procedures from this program for other programs I write for other classes.) The programming schedule was broken down into several 'benchmarks,' at which time our program was supposed to be able to do a certain set of tasks. The next benchmark required another set of tasks. This more or less simulated maintenance. It was, however, required that the project was the effort of only one student. As far as 'programming environments' (I assume development environment) are concerned, I found that my humble Apple //e far and away blew out any online editor available (but then, I had to use these editors over a 1200 baud modem). I also found out that it takes a l*o*n*g time to up/download a 90K source code. -- Mike Jetzer "If you can't be right, be forceful" uwvax!uwmcsd1!marque!studsys!jetzer
friedl@vsi.UUCP (Stephen J. Friedl) (03/30/88)
In article <3326@zeus.TEK.COM>, karenc@amadeus.TEK.COM (Karen Cate) writes: > 2. One teacher had us write a program and hand it in. He then randomly > distributed them back to the class. We then had to add/modify this > other students' program. This was the second CS class we took, so > we: a) learned a whole lot, and b) none of ours was good enough that > we took offence at the comments of our peers (as a general rule). > There was not one complaint about requiring comments after that. > It also taught us the difference between helpful comments and the > stuff you put in to please the TA. What a great idea! How many times have you heard (or said!) in school "Yea, I'm done with the program, now I have to put in the comments". Even after almost three years of heavy commercial development I am still learning how to put in good documentation that *means* something to a maintainer (i.e., me) a year down the road. Students need to learn what the word "maintenance" means... The rest of Karen's comments are equally good as well. -- Steve Friedl V-Systems, Inc. *Hi Mom* friedl@vsi.com {uunet,ihnp4}!vsi.com!friedl attmail!friedl
jwg1@bunny.UUCP (James W. Gish) (03/31/88)
There have been a number of comments indicating that you can't get the experience in school that you can get in industry doing large scale system development. I agree. However, a large part of this has to do with the traditional mode of thinking about how courses are structured, i.e. one or two self contained semesters centered around closely related topics. If you break out of this traditional structure and choose a large complex system that is continually evolving as the focus of the design, programming, maintenance, project management, enhancement, testing, prototyping... assignments over a four year period you could better address some of the concerns about getting a feel for realistic system development. You could still have one or two semester self contained courses, but the projects could revolve around this large system. Naturally, it would be hard to manage, but isn't that the point? It also would "never be done" (another characteristic of many/most real software products). Of course, subsystems would get done. I can see lots of opportunity here for addressing the concerns raised in this discussion group. Possible projects: OS, DBMS, programming environments (CASE, rapid prototyping, visual,...), object management systems, ... -- Jim Gish GTE Laboratories, Inc., Waltham, MA CSNET: jwg1@gte-labs UUCP: ..!harvard!bunny!jwg1
chris@metavax.UUCP (Chris Collins ) (03/31/88)
In article <87@studsys.mu.edu> jetzer@studsys.mu.edu (jetzer) writes: > My (heavily commented) source code was about 2400 >lines long; this may or may not seem long to professional programmers, but >it's a far cry from the < 200 line programs that are typically assigned in >the intro to pascal course. >Mike Jetzer >uwvax!uwmcsd1!marque!studsys!jetzer This class sounds like a good start, but it must a) increase the complexity of the software to approximately 10,000 lines, and b) should be increased to more than 1 credit hour accordingly. It is my experience that a programmer only begins to appreciate comments, design, modularity, etc. when the software he is working on exceeds the amount of lines of code he could mentally assimilate. For me, and for others I have discussed such things with, this is about 10,000 lines. The language doesn't matter too much for this limit. The increase in credit for such a course is for 2 reasons. First, to cover the increased work in handling 10,000 line programs. Secondly, at the U of Michigan, where I attended, one credit courses were not looked upon by students as ""real"" classes. This may not be true at other institutions of learning. ------ /MM/\MM\ META SYSTEMS, LTD. /MM/ \MM\ 315 E. Eisenhower /MM/ /\ \MM\ Suite 200 === == === Ann Arbor, MI 48108 \SS\ \/ /SS/ \SS\ /SS/ Chris Collins, Senior Programmer \SS\/SS/ ------ My colleagues chastised me for not saying these aren't my company's opinions. Companies don't have opinions.
msir_ltd@ur-tut (Mark Sirota) (03/31/88)
It would seem that the gist of this conversation is that college CS
departments aren't teaching proper programming skills. I have two major
points to make on this:
(1) As has been pointed out by several people, you can't just "teach"
programming skills; experience is really the only tutor here. (You can
teach *techniques*, but I claim that they're not learned until they're
used. You can tell a student what to use, but he/she hasn't learned it
until he/she has done so.)
To get around this, people have suggested writing 10,000 line
programs, or continually working on the same program for 4 years.
This is fine; it closely mirrors what actually happens out there in
the programming world. However, I really don't think it will ever
happen in colleges; these things are really too hard to manage.
In the real programming world, you spend 8 hours a day (more or less)
working on distinct projects, with a goal and deadline in mind,
frequently with other people, taking care to make this well-done
enough for other people to work on once you're done with this job.
In school, you write a program to cater to the audience that will read
it, much as you write an English paper. In this case, the audience is
usually just the grader. You can usually assume the grader knows the
language you're using, so you can skip those silly comments, but in
the real world this may not be the case. (Note that this is just one
simple example; differences like this abound.)
Another example is the introductory programming course - You can tell
people what a linked list is, but they're never gonna understand until
they use one.
What I'm getting at is that work experience is really the only way to
properly teach programming skills; classes can only approximate it.
(2) Computer Science departments *shouldn't* be teaching programming
skills anyway; leave that to the Software Engineering department.
Other disciplines haev separate Science and Engineering departments,
like Physics/Mechanical Engineering, Chemistry/Chemical Engineering,
and the like. Why not have Computer Science/Software Engineering?
(Hardware Engineering exists too; it's usually called Computer
Engineering, which I don't think is really very fair.)
Here at the University of Rochester, the CS department churns out some
damn good computer scientists. Most of them can't program to save their
lives, and they often hate the programming courses in the curriculum. It
is important to recognize the difference between a software engineer (some
call it a "programmer" and a computer scientist.
--
Mark Sirota
msir_ltd%tut.cc.rochester.edu@cs.rochester.edu (rochester!ur-tut!msir_ltd)shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (03/31/88)
In article <5775@bunny.UUCP> jwg1@bunny.UUCP (James W. Gish) writes: >[...] If you break out of this traditional >structure and choose a large complex system that is continually >evolving as the focus of the design, programming, maintenance, project >management, enhancement, testing, prototyping... assignments over a >four year period you could better address some of the concerns about >getting a feel for realistic system development. [...] This is actually rather common, at least on an informal basis. Good students (mostly grads, but some undergrads) will get involved in some major ongoing research project, at the level of maintenance/enhancement. The experience can be extremely realistic, depending on the project! Problems are several: employers may not consider such activities to be "real experience", students not participating will be handicapped later on, perhaps without realizing it, time can be consumed by clerical work that would have been better spent on classes, and so forth. It's not clear that a formal mechanism for projects would be any improvement, though. stan shebs shebs@cs.utah.edu
hollombe@ttidca.TTI.COM (The Polymath) (04/02/88)
Just to add another aspect to the discussion of education vs. real world
experience, the following ad appears in the positions offered section of
the Communications of the ACM, March 1988, page A-36 (spelling, grammar
and punctuation are theirs, elipses are mine):
INDUSTRIAL POSTIONS FOR
COMPUTER PROFESSIONALS
Positions nationally. Fees paid by em-
ployers. U.S. citizens or permanent res-
idents. PhD or minimum three years, <== Note
experience. Call or write ... [etc.]
Of course, that's just one recruiter's opinion. Makes you wonder, though.
My experience has been that CS degrees and CS competence are not closely
related.
I agree with the need to bring more of the real world into the class room.
I've had to clean up too many messes that would probably have received a
passing grade because they worked (until a boundary condition, or
something else unexpected, tripped them up).
I'm cross-posting to misc.jobs.misc because the degree question often
comes up there. Please edit the Newsgroups line appropriately before
following up.
--
The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM) Illegitimati Nil
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 452-9191, x2483
Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombeshebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (04/03/88)
In article <2218@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: > Positions nationally. Fees paid by em- > ployers. U.S. citizens or permanent res- > idents. PhD or minimum three years, <== Note > experience. Call or write ... [etc.] > >Of course, that's just one recruiter's opinion. Makes you wonder, though. Based on my recent experience in jobhunting, equating a PhD with however many years it took you to get it is quite common. Based on observation of PhDs in industry, if you take a job where they think that way, you will deserve whatever you get, which generally means almost zero creative work. The main use of your degree will be to pad proposals ("we're going to have 45 PhD researchers working on this project, if you give us the bucks"). Personally, I've sweated over my PhD too much to have it counted the same as warming a chair for five years. >My experience has been that CS degrees and CS competence are not closely >related. s/CS//g - this isn't some special defect of CS degrees. A while back I read some flame in an IEEE rag about how EE grads don't know the right things, and my dad the non-degreed (not even BS) research chemist has told some amusing stories about the ignorance of new chemistry PhDs. A degree is more like some minimum requirement than a glowing recommendation. If you can't manage to get a BS these days, you've got to be really defective somehow, like maybe you can't tear yourself away from a terminal long enough to find out that bubble sorts aren't the only choice! (flames launched, sir - tracking...) stan shebs shebs@cs.utah.edu
g-rh@cca.CCA.COM (Richard Harter) (04/04/88)
In article <5388@utah-cs.UUCP> shebs%defun.utah.edu.UUCP@utah-cs.UUCP (Stanley T. Shebs) writes: >In article <2218@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: Positions nationally. Fees paid by em- ployers. U.S. citizens or permanent res- idents. PhD or minimum three years, <== Note experience. Call or write ... [etc.] This is clearly a typo -- it should read "PhD and three years experience or no PhD". :-) -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
stank@orca.TEK.COM (Stan Kalinowski) (04/04/88)
In article <5388@utah-cs.UUCP> shebs%defun.utah.edu.UUCP@utah-cs.UUCP (Stanley T. Shebs) writes: >Based on my recent experience in jobhunting, equating a PhD with however >many years it took you to get it is quite common. I think industry equates the time to earn a degree with equivilent time in the field because it is looking for results. Having a PhD does not necessarily guarantee results, having a good track record of results usually does. Industry tends to lay blame on our educational system. The hiring policy makers say that PhD's with no industry experience have difficulty making the transition from theoretical science to applied science and that PhD's don't know how to translate ideas into dollars. The following observation might illustrate what I'm getting at: A couple of years ago I read an article in the Sunday New York Times that said PhD's in Artificial Intelligence graduating from a leading school could earn something like $70,000. The article said that the starting salary was so inflated because of high demand for, and a small supply of Ai PhD's. I take this to mean that industry has spent a great deal of money on developing AI expertise. So far, I haven't heard of any companies reaping an acceptable gain on their investment in AI technology. AI has been applied mostly to internal systems development having only limited cost saving value. The few comercial products that use AI technology have met with only limited success. Perhaps it's too soon to tell, but it seems that in these days of "quick buck" business investment the AI PhD's have not been able to convert their knowledge into bottom line bucks. Who's to blame? Industry says that the fault lies with the educational system for not teachiing students how to apply technology profitably. Educational institutions blame industry for not providing enough financial support for education, for not fostering creative application of ideas, and for expecting too much from technology. The only conclusion I can make from all this is: IF WE DON'T CHANGE THE WAY WE ARE DEVELOPING AND MARKETING TECHNOLOGY WE WILL ALL LOSE! << DISCLAIMER >> The above opinions are my own, and are not necessarily representative of the company I work for (Tektronix). Please don't FLAME me if you diasgree with my analysis. I have merely stated my current opinion and I am open to calm, open-minded, discussion of these issues. I can even be persuaded to change my opinions when given a resonable counter argument. -- US Mail: Stan Kalinowski, Tektronix, Inc. Information Display Group, Graphics Workstations Division PO Box 1000, MS 61-028, Wilsonville OR 97070 Phone:(503)-685-2458 uucp: {ucbvax,decvax,ihnp4,allegra,uw-beaver}!tektronix!orca!stank
jmm@thoth20.berkeley.edu (04/04/88)
(Disclaimer: I'm not any variety of engineering major, nor have I much experience in the world of business.) I always thought that universities were supposed to teach theory more than practice. There are going to be lots of different types of systems out there in the 'real world,' and if your educational background only prepares you to use one of them then it doesn't do you much good. If your education teaches you the general way that systems are built, why they're built that way, and leads you to think about new ways they could be designed, then your chosen place of employment can teach you the specific way it's implemented. Universities should not be expected to teach people the uses of any particular set of tools. That's what vocational schools are for. / James Moore / | jmm@bartleby.berkeley.edu / / |--------------------------------------------| / Ma ta Gaeilge agut, / | Nil aon speis ag Ollscoile na | / scriobh i! / | California im bharulacha fein. |
shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (04/04/88)
In article <2524@orca.TEK.COM> stank@orca.UUCP (Stan Kalinowski) writes: >I think industry equates the time to earn a degree with equivilent >time in the field because it is looking for results. Having a PhD >does not necessarily guarantee results, having a good track record of >results usually does. Industry tends to lay blame on our educational >system. The hiring policy makers say that PhD's with no industry >experience have difficulty making the transition from theoretical >science to applied science and that PhD's don't know how to translate >ideas into dollars. What's the definition of "results"? Published papers or software profits? There are at least two assumptions here: one, that PhDs do "theoretical science", and that a PhD is necessary to do "applied science". Of course, people have differing ideas of theoretical vs practical - I've been accused of being "too theoretical" and "too practical" at the same time (but, fortunately, not by the same person :-) ). As I said previously, there is a habit of companies specifying "PhD" when they really want a good person with a master's. So let me ask this: does anybody actually know why companies specify PhDs when they have no intention of letting the employees do either basic or applied research? Or is it that the definition of "applied research" covers anything more creative than buying a commercial software package? >The only conclusion I can make from all this is: IF WE DON'T CHANGE >THE WAY WE ARE DEVELOPING AND MARKETING TECHNOLOGY WE WILL ALL LOSE! I don't understand who is going to lose what. Technology transfer is already incredibly efficient, so much so that many senior people in the field worry about loss of academic freedom because of companies insisting on funding only short-term work with clearly-defined goals. stan shebs shebs@cs.utah.edu
ee4011ab@ariel.unm.edu (Mark P. Martin) (04/05/88)
In article <8295@agate.BERKELEY.EDU> jmm@thoth20.berkeley.edu.UUCP () writes: >I always thought that universities were supposed to teach theory more than >practice. They do, greatly in error and to the disadvantage of the student. Employers are not looking for people with extroardinary skills in practicing theory, but for people with extensive experience in a multitude of systems, languages, and environments. NO, strike that! They are looking for experience on *their particular system*. Presumeably, this experience has been acquired elsewhere, as the employer finds it economically advantageous to hire capable people, rather than train new people. Some college programs seem to be realizing the fallacy of teaching extensive theory with no practical application, but in general the effort put forth is not effective. Consider the course in which the senior project is to develop and market a large software project: the primary objective in the course was to satisfy the instructor's emotional need for the use of non-sexist pronouns. :-) The secondary objective was to produce appealing packaging (never mind what went in) for the project. With so much emphasis on satisfying the instructors requirements, the true needs of the paying client were seen as "soft requirements." Not that packageing and user interface are unimportant, but I believe that employers looking for engineers would be more interested in academic work writing UNIX device drivers than poetic prose with little technical content. >Universities should not be expected to teach people the uses of any particular >set of tools. That's what vocational schools are for. I have yet to hear about a vocational school that teaches all the aspects of the internal design, programming and operation of computers, and still maintains a quality reputation. Vocational schools are not recognizeable degree granting institutions in such fields as engineering. And engineering is more ability to apply knowledge than the straightforward use of tools and techniques. The word "engineer" derives from "engenious man" (no sexism flames please, I have a reference). *-----------------------------------------------------------------------------* | "People can be divided into three categories: | Mark P. Martin | | Those who make things happen, | B.S.Comp.E - UNM | | Those who watch things happen... | ee4011ab@ariel.unm.edu | | and those who wonder what happened." | | *-----------------------------------------------------------------------------*
cramer@optilink.UUCP (Clayton Cramer) (04/05/88)
> In article <2218@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: > > > Positions nationally. Fees paid by em- > > ployers. U.S. citizens or permanent res- > > idents. PhD or minimum three years, <== Note > > experience. Call or write ... [etc.] > > > >Of course, that's just one recruiter's opinion. Makes you wonder, though. > > Based on my recent experience in jobhunting, equating a PhD with however > many years it took you to get it is quite common. Based on observation of I can remember some years back seeing an ad in the LA Times that said, "Minimum five years experience. Will consider two years graduate work equivalent to six months paid experience." And from my own days as a headhunter, a quote from a woman who was data processing manager for a major cosmetics manufacturer, "Don't send me anyone with a M.S. They don't know how to DO anything." Clayton E. Cramer
klee@daisy.UUCP (Ken Lee) (04/06/88)
Graduate degrees can be very valuable. Sometimes they're worthless. It all depends on the position. A research lab or university may require a PhD for certain positions, perhaps under the assumption that the education you received will add to your performance. Hacker houses may not care if you have any degree. It's up to you to choose a job that matches your career goals. You may also want to consider a degree that matches. Ken -- New simplified tax form: Line 1: how much money did you make? Line 2: send it in.
rhj@wdl1.UUCP (Bob Jones) (04/06/88)
Some observations on commented code: > What a great idea! How many times have you heard (or said!) in > school "Yea, I'm done with the program, now I have to put in the > comments". Even after almost three years of heavy commercial > development I am still learning how to put in good documentation > that *means* something to a maintainer (i.e., me) a year down the > road. Students need to learn what the word "maintenance" means... > I have been writing code for over twenty years, now and couldn't agree more with the above sentiments. My basic rule of thumb is: I always maintain a healthy paranoia of having to maintain my own code. Healthy comments make this paranoia managable. In 1978 and 1979, I wrote Tandem's DDL compiler. In 1986 I returned to Tandem as a consultant to help enhance the DDL compiler. The comments I wrote in '79-'79 made it possible for me to relearn the code very easily. And the places I had failed to comment came back to haunt me. The premise that one will put comments in later is in a class with comments like "the check is in the mail". Believers in this premise most likely still believe in the tooth fairy. Adding comments as you go is the only way to fly. It may require a small amount of additional time up front, but the payoff is huge down the road. Poorly commented code is, in my personal opinion, one of the key indicators of an immature and impatient programmer. Bob Jones Ford Aerospace
msir_ltd@ur-tut (Mark Sirota) (04/06/88)
In article <3850007@wdl1.UUCP> rhj@wdl1.UUCP (Bob Jones) writes: > The premise that one will put comments in later is in a class with > comments like "the check is in the mail". Believers in this premise most > likely still believe in the tooth fairy. > > Adding comments as you go is the only way to fly. It may require a small > amount of additional time up front, but the payoff is huge down the road. > Poorly commented code is, in my personal opinion, one of the key > indicators of an immature and impatient programmer. Agreed, but allow me to break this up a little further. I *never* add in-line comments until I'm done writing and testing the algorithm or procedure in question. There is such a thing as over-commenting, and the threshold is much lower when the code is incomplete. Sometimes comments just get in the way and make the code harder to read, so I generally prefer a "how" and "why" (as opposed to "what") comment at the top of a section of code, with nothing inside. "what" comments can be added later, as appropriate, to clarify complicated code for the future. So I think it's a mistake to make a blanket claim that adding comments later reflects an immature programmer; sometimes it simply makes more sense to do it that way. -- Mark Sirota msir_ltd%tut.cc.rochester.edu@cs.rochester.edu (rochester!ur-tut!msir_ltd)
dalamb@qucis.UUCP (David Lamb) (04/07/88)
This discussion has wandered into CompSci/SoftEng differences, and theory versus practice at universities. Last year I finished writing a SoftEng textbook (apologies for implied commercial message), so had to do some thinking about these issues. All these "statements" are really opinions. 1. Most undergraduate programs don't have a serious distinction between CS and SE; if we reorganised the curricula to make a distinction, there'd be a lot fewer people in CS programs. 2. A University is supposed to put more emphasis on education than on training. Nobody can draw a sharp boundary between the two, but there are differences: training gives you more specific and thorough understanding of something particular and concrete, education gives you mental tools to understand, learn, and adapt. 3. The engineering disciplines teach you how to apply principles to solve problems, using existing technology mainly to have a means to talk about the principles. That's what makes an engineer different from a technician; the technician typically learns only a particular technology, and needs retraining every few years. A job interviewer that puts a lot of weight on to want experience with a particular collection of tools is asking for a technician, not a University grad. 4. There is nothing so practical as a good theory - one that gives you a framework for understanding and solving your problems. The problem with too many "theoretical" courses isn't that they are theory, but that they don't connect the theory very well with practice. 5. A Ph.D. is only evidence of research ability in a specialised field. From some institutions you are also made to learn a lot about a much broader field first, as part of the comprehensives. A lot of "Advanced Development" jobs asking for Ph.D.'s probably only need the broad (but reasonably deep) background - which plenty of people without Ph.D's can develop on their own. David Alex Lamb Queen's University Kingston, Ont, K7L3N6
al@gtx.com (0732) (04/07/88)
In article <2000@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes:
->
->I can remember some years back seeing an ad in the LA Times that said,
->"Minimum five years experience. Will consider two years graduate work
->equivalent to six months paid experience." And from my own days as a
->headhunter, a quote from a woman who was data processing manager for a
->major cosmetics manufacturer, "Don't send me anyone with a M.S. They
->don't know how to DO anything."
->
One of the reasons for getting an advanced degree is so you don't have to
work in the data processing division of a large cosmetics manufacturer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
( Alan Filipski, GTX Corp, 8836 N. 23rd Avenue, Phoenix, Arizona 85021, USA )
( {ihnp4,cbosgd,decvax,hplabs,amdahl,nsc}!sun!sunburn!gtx!al (602)870-1696 )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~doug@edson.UUCP (Doug Konrad) (04/07/88)
In article <1664@ur-tut.UUCP>, msir_ltd@ur-tut (Mark Sirota) writes: > In article <3850007@wdl1.UUCP> rhj@wdl1.UUCP (Bob Jones) writes: > > The premise that one will put comments in later is in a class with > > comments like "the check is in the mail". Believers in this premise most > > likely still believe in the tooth fairy. > > Agreed, but allow me to break this up a little further. > > I *never* add in-line comments until I'm done writing and testing the > algorithm or procedure in question. There is such a thing as > over-commenting, and the threshold is much lower when the code is > incomplete. Sometimes comments just get in the way and make the code > harder to read, so I generally prefer a "how" and "why" (as opposed to > "what") comment at the top of a section of code, with nothing inside. > "what" comments can be added later, as appropriate, to clarify complicated > code for the future. The problem with Mark's technique arises in situations where there is significant deadline pressure... Do you really think that adequate time will be spent commenting code when the boss is breathing down your neck? Even if the boss grudgingly agrees to allow you the time, how many programmers will resist the temptation to cut corners (and keep their job) when the boss drops by their cubicle and says, "Just about done? We've got to finish project 745 - project 746 is a rush..." Suggestions that one needs a new boss are not particularily constructive - any organization must watch its efficiency closely if it is to succeed. Any boss will have to be careful that his department wastes little time. The difficulty is that so many people have trouble seeing the work that occurs after a product seems to work according to spec as crucial as work that occurs before. So... my suggestion is that you comment while you code. Then, when it runs, its done. Doug
doug@edson.UUCP (Doug Konrad) (04/08/88)
In article <2705@charon.unm.edu>, ee4011ab@ariel.unm.edu (Mark P. Martin) writes: > In article <8295@agate.BERKELEY.EDU> jmm@thoth20.berkeley.edu.UUCP () writes: > >I always thought that universities were supposed to teach theory more than > >practice. > > They do, greatly in error and to the disadvantage of the student. Employers Compare this statement with the ones below. > are not looking for people with extroardinary skills in practicing theory, > but for people with extensive experience in a multitude of systems, > languages, and environments. NO, strike that! They are looking for > experience on *their particular system*. Presumeably, this experience has > been acquired elsewhere, as the employer finds it economically advantageous > to hire capable people, rather than train new people. In other words, employers want people with skills in the straightforward use of tools and techniques. > I have yet to hear about a vocational school that teaches all the aspects > of the internal design, programming and operation of computers, and still > maintains a quality reputation. There is a reason for that. Such is the domain of an institution which teaches theory. If you try to design something, and don't understand the underlying theory governing that something, you aren't an engineer, you're a parrot. > Vocational schools are not recognizeable > degree granting institutions in such fields as engineering. And > engineering is more ability to apply knowledge than the straightforward use > of tools and techniques. The word "engineer" derives from "engenious man" > (no sexism flames please, I have a reference). Here you come around and agree with me. (How can we have a good argument if you insist on agreeing with me?) However, this wasn't what you said in your first paragraph. I am reminded of the statement of a character from the TV program "Paper Chase". The show centred around a law school. "You will teach yourselves the law. I will teach you how to think." A bit pretentious, but it captures the role of a university. When I had finished my undergraduate degree, I had learnt how to design microprocessor hardware, and how to think like an engineer. The latter made a lot more money for my employer than the former. Even if he didn't think so. By the way, I am taking a broad view of theory. I mean much more than those interminable classroom lectures on quicksort. For software engineering, it includes examination of large systems. And it includes looking at challenges where the theory is incomplete. Doug
rhj@wdl1.UUCP (Bob Jones) (04/08/88)
Responding to comments by: / msir_ltd@ur-tut (Mark Sirota) / 11:03 pm Apr 5, 1988 / > I *never* add in-line comments until I'm done writing and testing the > algorithm or procedure in question. There is such a thing as > over-commenting, and the threshold is much lower when the code is > incomplete. Sometimes comments just get in the way and make the code > harder to read, so I generally prefer a "how" and "why" (as opposed to > "what") comment at the top of a section of code, with nothing inside. > "what" comments can be added later, as appropriate, to clarify complicated > code for the future. > > So I think it's a mistake to make a blanket claim that adding comments > later reflects an immature programmer; sometimes it simply makes more > sense to do it that way. Let me categorize comments into four groups: 1) Descriptive comments on the entire module 2) Descriptive comments at the begining of each function 3) Block comments at the begining of significant sections of logic 4) Line comments describing a variable or line of code I would agree with Mark's observation about the value of putting some comments in after the algorithm is completed, but I would insist that the function header and module header comments should always preceed the writing of the code itself. This doesn't necessarily mean that you write these comments only once and never update them; however, if you don't know what a function or a module (i.e. a collection of related functions) is going to do before you start writing the code, then you really have not thought the problem through well enough to start coding it. I find that the very act of writing the comments forces me to think the problem through; and I often find that while I am writing these function level comments, I see a design problem that I can still correct easily. Correcting it after it has been coded is much harder. The block logic comments can be put in either before or after you have coded the logic without much impact on the end result. Line level comments are not of much use, except as used to describe variables or standard definitions. I must stand by my earlier assertion: Comments (in the large) should be written before the code. They serve to assure that you know and understand what you are coding. If you can't describe it in plain English, you probably can't code it in a reliable and maintainable fashion either. Bob Jones Ford Aerospace
cdshaw@alberta.UUCP (Chris Shaw) (04/08/88)
In article <3850007@wdl1.UUCP> rhj@wdl1.UUCP (Bob Jones) writes: >My basic rule of thumb is: > > I always maintain a healthy paranoia of having to maintain > my own code. > >Healthy comments make this paranoia manageable. > >Bob Jones >Ford Aerospace Very true. Actually, one of my more satisfying recent software writing experiences came last year while I was consulting. The firm I was consulted by had a very poorly documented piece of hardware that needed a real-time software driver. There followed a very frustrating round of interviews with somewhat Un-professional engineers regarding the true features of the botch I was to write software for. This process was eventually completed, and I spent the next while writing the design document. I then spent what seemed like three minutes coding it up. I even managed to discover an obscure IO bug, which I spent an inordinate amount of time working around. It's one of those interesting things. Documentation is easy throw away, but code is hard (psychologically) to pitch. If you settle all the design issues with text only, you will probably end up with a better design. I imagine it's because text is a lot easier to read (and therefore critique) than is code. The major point being that with a solid external document, maintenance is likely to be very straightforward. Of course, my motivation for thoroughness was a desire to never hear from these people again, unless they had another contract for me. As for comments, I don't recall. These people had a very nice standard for documenting variables and so on, so I followed that fairly carefully. -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !
friedl@vsi.UUCP (Stephen J. Friedl) (04/08/88)
In article <3850007@wdl1.UUCP>, rhj@wdl1.UUCP (Bob Jones) writes: > Adding comments as you go is the only way to fly. It may require a > small amount of additional time up front, but the payoff is huge down > the road. Poorly commented code is, in my personal opinion, one of > the key indicators of an immature and impatient programmer. Very good point. I have found that writing function-header comments *before* writing the described function helps in two ways: (A) it insures that the comments go in and (B) it helps me define *exactly* what the function does. I describe aloud to an imaginary officemate what the function does, then put that description in the comment. Many times I would need some function but would have only a general idea what it was supposed to do. The documentation ahead of time helps me nail down those important little details (resets the counter or not, closes the file or not, increments the pointer or not, etc.). -- Steve Friedl V-Systems, Inc. "Yes, I'm jeff@unh's brother" friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
pepper@dasys1.UUCP (Angelique Wahlstedt) (04/08/88)
In article <8295@agate.BERKELEY.EDU> jmm@thoth20.berkeley.edu.UUCP () writes: >I always thought that universities were supposed to teach theory more than >practice. There are going to be lots of different types of systems out there >in the 'real world,' and if your educational background only prepares you >to use one of them then it doesn't do you much good. If your education >teaches you the general way that systems are built, why they're built that >way, and leads you to think about new ways they could be designed, >then your chosen place >of employment can teach you the specific way it's implemented. > >Universities should not be expected to teach people the uses of any particular >set of tools. That's what vocational schools are for. Good point! HOWEVER, sometimes I feel that half the stuff that computer science programs in many schools teach is pretty irrelevant to the Real World. For example, at Colorado State University, I'm taking CS-201 (Discrete Structures) (simply cuz CSU told me to. :-) that covers all sorts of things from binary trees to boolean algebra. Some of those, obviously, have uses in the Real World, such as binary search trees. But, to this day, I still can't figure out what applications some of the other things, such as monoids and isomorphisms (if you don't know what they are, don't ask ME :-) have in the real world. I'm also taking Symbolic Computing (LISP and Prolog) which is fun, but I doubt that most of us in the class would ever use either language in the Real World. Some of the courses that I think should be required in college are Software Engineering and Technical Writing (some colleges such as Rochester Institute of Technology already require this). Another possibility could be Database Concepts since so many jobs seem to involve databases. -- Angeli "Ms. Pepper" Wahlstedt UUCP: wahlsted@handel.colostate.edu - or - ...!hao!handel!wahlsted ...!dasys1!pepper (Big Electric Cat)
ee4011ab@ariel.unm.edu (Mark P. Martin) (04/08/88)
In article <121@edson.UUCP> doug@edson.UUCP (Doug Konrad) writes: >In article <2705@charon.unm.edu>, ee4011ab@ariel.unm.edu (Mark P. Martin) writes: >> In article <8295@agate.BERKELEY.EDU> jmm@thoth20.berkeley.edu.UUCP () writes: >> >I always thought that universities were supposed to teach theory more than >> >practice. ... deleted ... >> engineering is more ability to apply knowledge than the straightforward use >> of tools and techniques. The word "engineer" derives from "engenious man" >> (no sexism flames please, I have a reference). > >Here you come around and agree with me. (How can we have a good argument if >you insist on agreeing with me?) However, this wasn't what you said in your >first paragraph. My original intention was in saying that there should be practical application to accompany the teaching of theory, otherwise the theory will have only academic value. My earlier statements probably reflect my somewhat jaded view if the neanderthal nature of our national job getting system. I have been scanning the ads searching for languages, systems and other acronyms which match my background. This is to say that what employers appear to be looking for is not always the same as what they need, and not even the same as what they will get. And now I find at least one individual who holds dear the same values I do which make engineering valuable as a profession -- the desire and ability to solve problems. I thank you for bringing to light my ineffective presentation of our profession. Perhaps the lacking of this understanding in the universities and job places indicates a vacancy which either one of us could somehow correct, or at least use to advantage in seeking employment. *-----------------------------------------------------------------------------* | "People can be divided into three categories: | Mark P. Martin | | Those who make things happen, | B.S.Comp.E - UNM | | Those who watch things happen... | ee4011ab@ariel.unm.edu | | and those who wonder what happened." | | *-----------------------------------------------------------------------------*
klein%gravity@Sun.COM (Mike Klein) (04/09/88)
In article <3850008@wdl1.UUCP> rhj@wdl1.UUCP (Bob Jones) writes: |I must stand by my earlier assertion: Comments (in the large) |should be written before the code. They serve to assure that |you know and understand what you are coding. If you can't |describe it in plain English, you probably can't code it in |a reliable and maintainable fashion either. This goes together perfectly with my own experiences. If a module is commented in plain English (typically with simple "verb-object" descriptive pairs such as "initialize variables", or "allocate memory structures"), then the writer has thought about what it is doing and has conceptualized it well enough to express simply. At this point, the writer understands it, I understand it, and anyone else looking over it understands it. That means that any bugs, including the more pernicious ones such as logic errors or oversights, are more easily found. These comments should, as Bob says, be done *before* the coding has been finished so that logic and control flow has been thought out beforehand. -- Mike Klein klein@Sun.COM Sun Microsystems, Inc. {ucbvax,hplabs,ihnp4,seismo}!sun!klein Mountain View, CA
geoff@desint.UUCP (Geoff Kuenning) (04/09/88)
I don't have a Ph.D. in windowing graphics; in fact I don't have a Ph.D.
at all. Ph.D. or not, I simply don't have the background to design a
major windowing system like X-Windows. If I wanted to do so, I'd have
to hire somebody who *did* know, like perhaps a recent MIT Ph.D. grad.
On the other hand, those same friendly X-Windows folks recently released a
faster version of "make depend". Only one teeny problem: if you don't
have sources to cpp, the expression-evaluation routine (the one that handles
'#if <expression>' statements) reads, in its entirety:
return (TRUE);
As has been said before, I'd rather have correct code than fast wrong code,
thanks anyway.
The moral: if you have a "research-y" problem, get somebody with a
research background. If you want professional code, though, hire
somebody with professional experience; Ph.D. or not as appropriate. The
average new Ph.D. graduate is a beginning programmer by professional
standards, just like the average new Bachelor's/Master's graduate.
(P.S. Please don't get your hackles up, Bob; it's just one of many
examples I could cite from many sources. And yes, you'll be getting a
bug report on it.)
--
Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoffpeking@sfsup.UUCP (L.Perkins) (04/11/88)
In article <3763@dasys1.UUCP> pepper@dasys1.UUCP (Angelique Wahlstedt) writes: >Some of the courses that I think should be required in college are Software >Engineering and Technical Writing (some colleges such as Rochester Institute > >-- Yes, Yes, Yes. However, the real world has great difficulty communicating the necessity for good writing to faculty in Computer Science departments. While employed at a company whose managerial problems (including LACK of documentation of its products) was sending it down the drain, I was simultaneously taking courses from two different instructors, both with backgrounds in government and military systems, who said, in effect, that documentation was unimportant and merely something that junior people would have to put up with. Implication: as briefly as possible. Yet both individuals were members of professional associations that identified bad documentation as a key factor in the failure of HW and SW products "making it" in the marketplace. -- ________________________________________________________________ attunix!peking "The few, the proud, the red-haired" ---------------------------------------------------------------
hsd@uvacs.CS.VIRGINIA.EDU (Harry S. Delugach) (04/11/88)
In article <3850007@wdl1.UUCP> rhj@wdl1.UUCP (Bob Jones) writes: >Some observations on commented code: > >Adding comments as you go is the only way to fly. It may require a >small amount of additional time up front, but the payoff is huge down >the road. Poorly commented code is, in my personal opinion, one of >the key indicators of an immature and impatient programmer. What about short-sighted, "bottom-line" oriented company management which forbids you to "waste" time creating obviously non-functional comments, particularly if the project is perceived as easy or a "one-shot deal". Later when the "one-shot" is revived or modified, your new boss wonders why in the world you didn't forsee that it would be re-used. In such a case, it is often true that the real culprits (former managers) never have to face their mistakes. -- Harry S. Delugach University of Virginia, Dept. of Computer Science INTERNET: hsd@cs.virginia.edu UUCP: ..!uunet!virginia!uvacs!hsd BITNET: hsd2x@virginia
gcf@actnyc.UUCP (Gordon Fitch) (04/12/88)
In article <613@gtx.com> al@gtx.UUCP (Al Filipski) writes: }In article <2000@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: }-> }->I can remember some years back seeing an ad in the LA Times that said, }->"Minimum five years experience. Will consider two years graduate work }->equivalent to six months paid experience." And from my own days as a }->headhunter, a quote from a woman who was data processing manager for a }->major cosmetics manufacturer, "Don't send me anyone with a M.S. They }->don't know how to DO anything." } }One of the reasons for getting an advanced degree is so you don't have to }work in the data processing division of a large cosmetics manufacturer. Yeah, but people -- even PhD's -- want the money, and business is where most of it is, because that's where most of it comes from. I think this series of postings is fundamentally about whether advanced degrees are worth their high cost. The answer being given seems obvious.
geoff@desint.UUCP (Geoff Kuenning) (04/12/88)
In article <3850008@wdl1.UUCP> rhj@wdl1.UUCP (Bob Jones) writes: > I find that the very act of writing the comments forces me to > think the problem through; and I often find that while I am > writing these function level comments, I see a design problem > that I can still correct easily. Correcting it after it has > been coded is much harder. I couldn't agree more strongly. Recently, I discovered that my new ispell needed a *very* tricky routine. I spent over a week, on and off, writing the outline of the algorithm in the routine header. But once I got the comments right, it was very easy to write the routine itself. (For those who care and can remember for a couple of months until I post it, the routine is "combinecaps" and it's in the module makedent.c). -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
chris@metavax.UUCP (Chris Collins ) (04/12/88)
In article <2350@uvacs.CS.VIRGINIA.EDU> hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach) writes: >What about short-sighted, "bottom-line" oriented company management which >forbids you to "waste" time creating obviously non-functional comments, >particularly if the project is perceived as easy or a >"one-shot deal". Later when the "one-shot" is revived or modified, >your new boss wonders why in the world you didn't forsee that it would >be re-used. In such a case, it is often true that the real culprits >(former managers) never have to face their mistakes. >-- >Harry S. Delugach University of Virginia, Dept. of Computer Science > INTERNET: hsd@cs.virginia.edu > UUCP: ..!uunet!virginia!uvacs!hsd > BITNET: hsd2x@virginia When management "forbids" you to do your job correctly, you have only a couple of options: a) Look for other work immediately, and tell them why on the spot. Unfortunately I recognize that this is sometimes not possible. b) Tell them about the previous "one-shot" project that you spent untold hours deciphering at unbelievable cost. If you don't have one make one up, or ask about on the net. I'm sure many of us will gladly donate such a horror story. c) (my personal favorite) say, ok, and comment the code anyway. Somewhat humerous approach: Remark that "non-functional comments" are equivalent to "useful/intelligent managers". (This could result in option (a) above). Chris Collins
gcf@actnyc.UUCP (Gordon Fitch) (04/13/88)
In article <3042@sfsup.UUCP> peking@/doc/dmg/pekingUUCP (xt1124-AUG881-L.Perkins) writes: >In article <3763@dasys1.UUCP> pepper@dasys1.UUCP (Angelique Wahlstedt) writes: >>Some of the courses that I think should be required in college are Software >>Engineering and Technical Writing (some colleges such as Rochester Institute >> >Yes, Yes, Yes. >However, the real world has great difficulty communicating the >necessity for good writing to faculty in Computer Science departments. One of the reasons it has this difficulty is that the said Real World won't pay for documentation or the associated skills. Suppose you can both write well and program well: if you go where the money is, you'll never have anything to do with documentation. (In saying "Real World" I assume you speak about "business"; I don't know what the story is in academia, government, or other areas, but I'll bet it's the same.)
daveb@geac.UUCP (David Collier-Brown) (04/13/88)
Another response to the managerial "don't comment" dictate is very
simple: "Could you give me that in a memo please? I'd like to cover
my ass."
It's only slightly threatening, and expresses the risk involved to
both parties succinctly.
--dave (I've used a variant at another company, who shall remain
nameless) c-b
--
David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb
Geac Computers International Inc., | Computer Science loses its
350 Steelcase Road,Markham, Ontario, | memory (if not its mind)
CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.