perry@apollo.COM (Jim Perry) (05/03/89)
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.
warren@ihlpf.ATT.COM (Montgomery) (05/03/89)
I read this group only occasionally but was fortunate enough to stumble across Jim's posting on software engineering as practiced by DTSS. I worked at Dartmouth before him (when everything was done in assembly) and have much the same feelings about the quality and producitvity of the work done there. In addition to his reasons, I'd offer the following observations: The student programmers were chosen very carefully based on the non-credit course and placed very carefully in assignments according to what skills they showed. They were also there because they enjoyed the job, since it was not (during my era at least) seen as the route to fame in fortune it became in the early 1980's New people worked as apprentices to experienced developers in small teams. This allowed a lot better transfer of style and problem solving approaches than happens with typical job training programs. It also meant that designs and code got reviewed by at least one other person who was an expert at the system being modified and could effectively critique the strategy and style issues instead of focussing on superficial issues as is more typical of such reviews in large efforts. The primitive nature of the tools available (110 baud ttys and lots of batch compilation) forced people to be careful. People read and hand interpreted programs before compiling, and built in lots of trace information that was useful in diagnosing problems when something did fail. There were strong feelings of ownership and responsibility for the software. Ownership went out of fashion with "egoless programming", but I think it worked well in this environment at least. Programmers owned modules and when your module crashed, you got an octal dump in your inbox. The culture dictated that you figure out what caused each dump and fix it. Nobody liked being dumped on and everyone worked hard to keep their stack of unsolved dumps to a minimum. As to why you don't hear from more DTSS people, lots of them went on in other fields, and others are hacking away in various niches without access to anything like netnews and no particular interest in publishing. -- Warren Montgomery ihlpf!warren
scottg@hp-ptp.HP.COM (Scott_Gulland) (05/05/89)
> >Real programmers spend 90% of their time debugging. Computer science >curricula ignore debugging, perhaps because it can never be reduced I beg your pardon! YOU may spend 90% of your time debugging, but no one I have known in the last ten years of software development has spent anything close to 90%. Most engineers might spend at most 10% of thier time debugging. The vast majority of thier time is spent, developing internal and external documentation, design, coding, testing, and a wide variety of release related activities. Besides, if you write high quality code in the first place, you won't end up spending hardly any time at all debugging. Although a useful skill, it is definitely not in my top ten list. > Separating design from implementation is usually a mistake; ask the DoD.) Don't you mean to ignore implementation during design? I'll conceed that in some classes of applications that this might be true, but it is definitely not true in the general case (no blanket statements). > Other skills I would look for: > > 2. The ability to "port" software. This is an acid test for distinguishing > able programmers from mere C.S. grads. The problem is there are just not that many people (compared to the industry as a whole) performing this kind of work. In the last four years, the orginizations I have worked for has interviewed well over 500 canidates. Almost none of these canidates has had any significant porting experience. > 3. The ability to maintain somebody else's code. Most C.S. students have > no experience in this. Almost anyone can maintain someone else's code. The important question is how long does it take to become fluent in that code. Especially if it is poorly documented and/or poorly written. The amount of experience in this area can substantially affect their skills. > 4. The ability to work from specifications. This includes getting them > changed when they need it, and filling gaps by making inquiries or > using your own judgment. In some jobs this might be very important, but not in a lot of cases. In many of the jobs I seen and worked on, the development team itself develops the specs based on customer requirements or feedback (we spend a lot of time gathering this). Of course you orgnization may do things quite differently. > 5. The ability to write software with clean, convenient user interfaces. > A good programmer can "see" his software from the user's viewpoint > and write for the user's benefit. Excellent point! A very rare comodity indeed! > 6. The ability to write adequate user documentation. See 4. I whole-heartedly agree. > 7. Experience with a variety of languages, environments, and methods. > Not that this experience will necessarily prove useful, but it shows > that the programmer is versatile, and probably understands some of > the underlying principles of software environments. By the same token, > beware of dogmatism; a programmer with an antipathy to Pascal, COBOL, > or VAX/VMS may have a stiff neck. A programmer who stops learning > is technologically obsolete. AMEN! You be amazed at the number of people who claim to be engineers who are unwilling or afraid of learning a new languages, working on a new OS, etc. Experience combined with a solid CS background gives an engineer the confidence to tackle any new language, environment, etc. Scott G. scottg@hpiacla --------------
nick@hp-sdd.hp.com (Nick Flor) (05/06/89)
> >Real programmers spend 90% of their time debugging. Computer science >curricula ignore debugging, perhaps because it can never be reduced > Here, I made up a new one: Real programmers use only one CASE tool: vi. Copyright (c) 1989, Nick Flor All rights reserved. Nick -- + Disclaimer: The above opinions are my own, not necessarily my employer's. + + "What's going down in this world, | Nick V. Flor * * o * * + + You got no idea. Believe me." | Hewlett Packard SDD * * /X\ * * + + -- The Comedian | ..hplabs!hp-sdd!nick * * / \ * * +
les@chinet.chi.il.us (Leslie Mikesell) (05/07/89)
In article <1670001@hp-ptp.HP.COM> scottg@hp-ptp.HP.COM (Scott_Gulland) writes: >>Real programmers spend 90% of their time debugging. Computer science >>curricula ignore debugging, perhaps because it can never be reduced >I beg your pardon! YOU may spend 90% of your time debugging, but no one >I have known in the last ten years of software development has spent anything >close to 90%. Most engineers might spend at most 10% of thier time debugging. >The vast majority of thier time is spent, developing internal and external >documentation, design, coding, testing, and a wide variety of release related >activities. Interesting that everyone has continued to express the time as a percentage of the total. Might this mean the the debugging and testing time is a constant and the "engineers" simply take longer to get the code written in the first place? Les Mikesell
ccs013@castor.ucdavis.edu (Jason) (05/08/89)
In article <8398@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: |In article <1670001@hp-ptp.HP.COM> scottg@hp-ptp.HP.COM (Scott_Gulland) writes: | |||Real programmers spend 90% of their time debugging. ^^^^^^^^^^ defined as soft. eng.'s ||I beg your pardon! YOU may spend 90% of your time debugging, but no one ||I have known in the last ten years of software development has spent anything ||close to 90%. Most engineers might spend at most 10% of thier time debugging. |Interesting that everyone has continued to express the time as a percentage |of the total. Might this mean the the debugging and testing time is |a constant and the "engineers" simply take longer to get the code written |in the first place? Oh no .... that isn't it at all.... that "100%" of time is only the 10% of the REAL time that the CS people wait around for the soft. eng's to get frustrated and give the work to them.... Now with CS, the time varies. Were what you'd call, variable and versatile. We are not little money craving robots drilled with applications and small scientific background. Its a shame how I find in college that ME's,CE's,EE's and AE's are NO MATCH for upper-division or graduate physics ..... and for EEC or ECS ..... they now about as much CS when they graduate at a lower division peon in CS. When the arrogant society of people with an "E" on the end of their degree get their noses out of the air and out of their wallets, and start nosing around in and appreciating PURE science, THEN and ONLY then can the let their pompus trash out.......until then... why don't you guys (and gals ... no predjudice here) .. go back to school.... ___ ___ __ ___ )___ ( | '__| (__ / / / / II Corinthians 10:17 \ | (__)\ __) /__/ / / \_| Internet: jygabler@ucdavis or ccs013@castor.ucdavis.edu | BITNET: jygabler@ucdavis | UUCP: ucdavis!jygabler or ucdavis!castor!ccs013