Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!apollo!perry From: perry@apollo.COM (Jim Perry) Newsgroups: comp.software-eng Subject: "software engineers" -- case study (long) Message-ID: <42fc20e4.183dc@apollo.COM> Date: 2 May 89 18:04:00 GMT References: <854@odyssey.ATT.COM> Reply-To: perry@apollo.COM (Jim Perry) Organization: Apollo Computer, Chelmsford, MA Lines: 105 The term "Software Engineering" was coined since I studied programming, but I agree with Col. Sicherman that what people talk about now as the qualities of a Software Engineer are what I learned as those of a Programmer, a good one at least. I studied at Dartmouth College, in the late '70's, the high days of the Dartmouth Time Sharing System. That system (a large mainframe timesharing system) was written in the mid '60's by math professors and undergraduate students, and maintained ever since primarily by undergraduate students. It wasn't a research project or a commercial venture, it was a tool to make computing resources available to the college at large. The potential problems should be obvious: in those days freshmen rarely had much previous experience, and by the time you've trained such a person to the level of working on the innards of your OS kernel (remember, this is a full-production 300-user timesharing system) they're pretty close to graduation [or expulsion, but that's another story...] Tricky, and yet DTSS has always enjoyed a reputation for quality, performance, and MTBF; "User Interface" was a buzzphrase at Dartmouth long before the days of window systems and mice. The system catered, and successfully, to naive users, and was successful in getting most of the undergraduate body to use the computer in days when that was unheard of. A quality system. How was this done with "mere" undergraduates? Through a Software Engineering culture (we didn't call it that) that I have not seen rivalled. The computer center ran a noncredit systems programming training course every fall, to acquire new recruits and start them on the Path. At the end of the course qualified students were offered part-time jobs. The course covered the systems programming language of the day (assembler [GMAP], then DXPL, then PL/I), but concentrated on style, which counted for much of the grade. Style included not only what seems the current vogue (whitespace, indentation, mixed case when it became available) but also documentation: selection of variable names and comments. The culture among the sysprogs maintained the emphasis ingrained during this course. Code was written to be read. It should be crystal clear what's going on at any point in the code, even to someone who's never read it (and after 25 years of maintenance by a population with a 4-year turnover, chances are they haven't read it). All new code was read by one or more peers and flaws, stylistic or algorithmic, were harshly treated. The documentation requirements were stringent. The favored style included long block comments at the beginning of a program describing what it was and what it did and who worked on it. Each procedure (ideally no more than a page) had a block comment describing what it did and how. Block comments were interspersed as needed to describe loops, tricky algorithms, etc. The use of "ascii graphics" was common in describing data structures or algorithms. Every variable was described at its declaration. In general, every line was commented, with a *useful and meaningful comment*. People who have never seen such programs generally balk here: they will complain that this much commenting is counterproductive, that programmers will insert meaningless comments (a = 1; /* assign 1 to a */), that comments will get out of date with code, etc. It just doesn't work that way. The culture was (is, I hope?) that comments are there to convey information and it has to be right or you take the heat (these are college students remember... can you say "peer pressure?") I can pick up a several-inch-thick program listing (nowadays a few microfiche cards) and get a good idea of what it does from the first pages, find out how the subsection I'm interested in works, and the details of the algorithm before even looking at code. (A compiler that generates pretty-printed listings with good indexes, table of contents, etc. helps; for instance line comments tabulated out to the middle of the page make it possible to read down the right side of the page for an English description of what's going on, or down the left to see how to do that in PL/I). I should add that partly because the math department (this is before Dartmouth had CS as a separate department) was heavily involved with DTSS and because the sysprogs and general DTSS hackers(*) tended to work as graders this culture was also represented in Computer Science classes. (*) Just to add to the historical record the word "hacker" as used at Dartmouth in this period (mid '70's) meant one who spent time exercising special knowledge to try to get around system security or to gain additional priviledges. Not maliciously, but as as an intellectual exercise. Bringing down the system or injuring another user's performance was a faux pas. Hacking was not actively discouraged, security holes so discovered were generally reported, and DTSS is pretty secure, as such things go (just guessing passwords didn't get you very far). I was in for a bit of a shock when I was exposed to the Real World :-). Yes, I still write as described, I think it works. It's a little out of the ordinary, but I don't get too many complaints. Maybe as new maintainers go to make changes they'll appreciate it, or maybe it really is purely cultural. I know it helps me. I often wonder why I don't see more stuff from old DTSS programmers on this group, possibly it's because we tended to be anti-UNIX bigots when it showed up and feel out of place now. Possibly it's because the typical DTSS programmer was as likely to be a philosophy or religion major as math/CS [DTSS code is also liberally sprinkled with literary references]. Plus, since DTSS wasn't a research project there was never much publication about it. But then I know there were other such development efforts at other schools. You occasionally see stuff from old Multics hands, but mostly the tone here is that UNIX sprang from the brow of the gods to save mankind from VMS. How about it: are there any other good cultural ideas we could all learn from? Or are we just doomed to keep reinventing wheels? This is very long, sorry. I don't consider myself the ideal apologist for DTSS although I used and worked on it for 10 years. I'm talking about 10 years ago; Dartmouth's more in the mainstream of CS now (for better or worse), and DTSS long ago officially got renamed Dartmouth College Time Sharing (DCTS) for legal reasons. My colleagues at Apollo write uniformly excellent code, if somewhat less verbose, on the whole, than mine :-). -- Jim Perry perry@apollo.com Apollo Computer, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.