http://invisible-island.net/personal/
Copyright © 2014–2019,2024 by Thomas E. Dickey

Papers versus Publication

Papers

Herewith, I give a brief history relating how (despite a promising start), I stopped producing grist for the academic treadmill, and focused on a more productive activity: developing interesting computer programs. (I offer my apologies for the mixed metaphor, in case anyone noticed).

1976

I was first introduced to the subculture of papers (and presentations) as a graduate student.

At the time, I was developing microprocessor assemblers and simulators. A student of Granino Korn's had published a paper in the October 1975 issue of IEEE Computer magazine which was essentially a simple cross-assembler written in BASIC, with some discussion to make it a publishable paper. My advisor brought it to my attention, and I typed the program in, finding that it had several errors which would prevent it from running. I pointed out that unlike my work, that was a single (monolithic) program with no reusable code.

To my advisor, the fact that the published program did not work was irrelevant; the point was publication. My advisor saw an opportunity at a nearby symposium to publish my work:

SIMIC: A Microcomputer Development and Evaluation Tool, C.P. Neuman and T.E. Dickey,
Trends and Applications 1976: Micro & Mini Systems
May 27, 1976
National Bureau of Standards
Gaithersburg, Maryland

At that point, I had written about 27,000 lines of code on my project (which eventually grew to about 85,000). My advisor and I had some differences for this paper:

Around the same time, I endured a "candidacy" for the degree. This is a practice run for the defense, for which I prepared by documenting (in several pages) my proposed research, the methodology used (as well as justification for the various aspects). Not being prepared, I had supposed we would talk about that. We did not. Abrahim Lavi (the senior faculty member of the group) had me go up to the chalkboard and begin working out a design for a feedback control system. This was fairly routine material—for a master's student. However, Lavi kept pouncing on pauses in my replies, apparently looking for a misstep. After 45 minutes of this exercise, he asked a question along the lines of “now what do you expect to happen if you make (this) change?”

I stumbled, starting to say “I think” This was what Lavi was waiting for (I can see that the process had a clearly defined goal). He said:

“Stop right there.” (I did, of course).

“A PhD does not think, a PhD knows.”

After allowing time for the lesson to sink in, he concluded with “You may sit down, now.”

The point that was being made is that recipients of the degree have demonstrated that they are detail-oriented. There is no guarantee about demonstrating their native intelligence (and I have encountered enough counter-examples to see that would be futile).

1977

Not long after that, I began working full-time at a research center. One of the last things that I did as a full-time graduate student was to design and develop an interpreter for a language which could describe the I/O and similar interfaces used in my simulations. I called this IDL (Interface Design Language):

I have a copy of a paper which Carlos Baradello wrote to submit to some conference (putting my name first, and adding Wolfgang Sauer as authors), referring to it as “IOL: Interface Operational Language” but I preferred IDL.

While I still had a lot of work to do (as a part-time graduate student, I worked “only” 30-40 hours per week on my research, along with 40 hours on my day job), the way in which I had allowed for bit-manipulation in IDL seemed good enough for a short paper, describing the design goals and tradeoffs. My employer was agreeable (it would not interfere with my job). I submitted the paper, and received mail confirmation that it had been accepted.

However, when I arrived at the conference, I found that something had gone awry. Though it had been accepted, at some point in the process it was lost (and not recorded). Fortunately, I knew one of the presenters (Alice Parker), who explained the issue to the people running the conference. I was allowed to make my short presentation, and got a few questions (such as where can one get the code). This was:

4th Annual Symposium on Computer Architecture,
cosponsors: IEEE Computer Society and ACM,
Silver Spring, Maryland, March 23-25, 1977

Overall, this was a more positive experience than the first. However, I found little time for external papers for a while. Internal research reports and memos, along with my graduate research took all of my time.

1981

In the course of my research, there was an unresolved dispute which festered away for a few years. My advisor (against my advice) reopened this issue. My adversary took this opportunity to attack my research, saying that programmer variability was “orders of magnitude” beyond the effect which I was measuring. While the political aspect was eventually resolved (largely due to my having at hand suitable documentation to demonstrate that my approach had been approved), I was curious what basis this criticism might have in fact.

Reasoning that the clues would be found in published literature, I spent a half-dozen Saturdays early in 1981 skimming through all of the technical and trade journals at the neighboring university's library (my own had a poor collection). I found what I was looking for (published papers in this area were very rare—probably no more than a dozen), and referring to the original paper, could see the flaws. Fortunately, the authors published their raw data. This allowed me to perform a standard ANOVA (analysis of variance) on the data. My computation showed me that the criticism applied had been unfounded.

Further, having found the (apparently only) source of this statement on programmer variability, I looked further to see how it had been referred to in the literature. There were several references, which (as time passed) grew into a sizable niche over the next 12 years. Discussing this example of folklore with Gary Leive, he offered the opinion that the reason why it had not been caught was just that it sounded so reasonable.

I saw an opportunity to publish a rebuttal in the most recent of these references, and got approval from my management to do this. The result appeared here:

Programmer variability, Dickey, T.E., Westinghouse Research and Development Center, Pittsburgh, PA
Proceedings of the IEEE (Volume: 69, Issue: 7)
July 1981, Pages: 844-845
Digital Object Identifier: 10.1109/PROC.1981.12087

as well as in my completed research. There was (inevitably) a rebuttal by Curtis in the Proceedings, to which I might have replied to. At the time, I had a copy from NTIS of a report on which the 1979 paper with Sheppard in Computer was based, likely one of these:

Both versions summarized the data, but did not present the raw data—which meant that independent analysis of the data as I had done for the Sackman paper was not feasible. Along those lines, I was concerned about Curtis's comment:

Data for 6 other professional programmers involved in this experiment were deleted, since they were unable to debug either the pretest or the experimental programs.

However, I was in the process of moving on to a new company, and had no time or opportunity to do this. By the time I had become settled there, Curtis had also moved—to a nearby division of the same company. Reopening the debate would have been awkward. Rereading the rebuttal in 2014, I see a different aspect: Curtis said:

Sackman's [3] message that substantial performance differences do exist among programmers remains valid. Detecting a 20+:1 range ratio depends upon having one brilliant and one horrid performance in a sample. However the range ratio is not a particularly stable measure of performance variability among programmers. The dispersions of such data as appear in Table I are better represented by such measures as the standard deviation or semiinterquartile range.

This is the answer which “Tony” was lacking: some authors read the first part of that paragraph only, while others read the whole paragraph. Curtis's mention of statistical measures is a reminder that because the extremes are relatively rare, they should receive less weight. Those who focus on the extremes (as in the beginning of this section) have ignored their due weight.

I completed my research (another publication, though calling Ann Arbor Microfilms “publication” seems to be stretching the point). I produced the book in two versions using txt and unover:

My book numbers pages within each chapter; a quick check shows 131 pages in the shorter version. That makes the full version about 590 pages. Another aspect of the publication requirement was to provide a copy for the university library. I did not like the idea of producing so large a book for the shelf (it would have been one of the largest, even after I tweaked the line-spacing and margins). Gary Leive said it was unnecessary to include any source code, saying that the computer science students for instance “never publish a line of code”. Not liking that idea, I discussed it with the library staff, who agreed that I could provide a book which was printed double-sided. (A few months later, I found that they had it reconstructed as a single-sided book, which could not have improved matters due to the way the margins are laid out—but I was gone—my copies look good).

I added a quote from Sackman's paper preceding the title page, with a footnote pointing out the irony of the text which I chose. Because the publication date for my book was May 14, 1981, that makes it the first published work to point out the problem with the 28:1 range. The IEEE Proceedings letter was published in July, 1981.

As of March 2014, Google Scholar has two entries referring to this. One is a mangled entry—wrong date, uses my initials rather than full name, and the “related articles” are for some secondary references which I used, and they have the title wrong:

Microprocessor Evaluation for Process Control Tasks
versus
Evaluation of Microprocessors for Process Control Applications

Hearing that I had decided to leave the R&D center, Carlos Baradello suggested I come where he was, at ITT. After looking at a few other possibilities, I did that.

1982

From late 1981 until mid-1983, I was a developer in the ITT 1240 system at the ATC (Advanced Technology Center) in Connecticut, mostly in the network maintenance area. Initially, Carlos was the team lead; he moved to a different position late in 1982. His replacement was Jamshed Mulla. Management seems to have higher turnover than development.

While the end application was written in CHILL (CCITT High Level Language), the compilers were hosted on MVS/TSO (a mainframe). The interactive front-end (running VM/SP CMS) had no development tools.

I wrote some tools (about 250 programs—mostly scripts but also some assembly language). A large fraction were to extend xedit. In the process of doing this, I wrote documentation for about 160 of these programs.

I wrote most of those programs to help with writing software and documenting my work. For instance (as a late-comer to the project), I immediately took on the smallest of the network maintenance applications—and shortly after, inherited the largest of these applications (from José Pozas, a Spaniard returning to his original company). There were only sketchy notes on its design. But there was a documentation requirement for the testing phase, with the scenario of inputs/outputs. I wrote a program which took the sets of test-data, and logs from running the program, and generated the roughly 250 pages of documentation needed. Thus far, good. However, when I proposed applying this to the remaining application, Jamshed objected, saying that I should not be doing Jan Schiets's work.

Jan Schiets, by the way, was from Belgium. According to Schiets, it rained all winter in Belgium and the sun never came out (a factor in my declining the offer from the BTM people a few years later). However, Connecticut had its moments as well (see this and this).

On the other hand, my work with the prtrcvr utility helped us prepare draft documentation on the CMS system which could be sent to the word processing group, preformatted in a way which greatly reduced the amount of work they needed to turn it into “real” documentation.

According to an associate, my programs were used at other sites; however none of those were (to my knowledge) published externally.

1983

I gave three presentations (at different conferences), and have comments on two more conferences.

Early in 1983 (perhaps in the spring), Jamshed said at the group meeting that there was a conference later in the year which was of interest, since one of the people on the program committee was in our department. That was GlobeCom '83. After the meeting, I suggested to Jamshed that if he would write an abstract for a paper describing our system and related development, I would write the paper. (He had been at ITT two years longer than I, and I wanted his input.) After further discussion, I wrote the abstract, but got him to agree to review the paper, to ensure that my presentation properly captured the sense of the jargon which we used.

Around the same time, Jamshed told us that there was to be an internal conference for ITT software development, and that abstracts for that were being accepted. The PTC (Programming Technology Center) was organizing this conference. I submitted abstracts for three (proposed) papers discussing my work:

After some time, Jamshed was able to report that

That done, he gave me back a copy of the abstract for “p”, which had redacted the reviewer's comments. I was able to read most of the comments; but not the reviewer's name (it's just as well, since the comments were not constructive). Setting those aside, I wrote a paper to match my abstract, and sent it in.

The PTC staff, it seems (from having reviewed resumes the following year) were generally my academic peers. However, discussing that topic with Jamshed early in 1983, I pointed out that ITT had no realistic career path for someone with my interests (either they would make a manager out of the person, or push him into a corner, to work on things that no one else understood). Aggravating this was the fact that administrative staff had picked up a (corporate) cultural idiosyncracy: in referring to someone above a certain level (no matter what credentials the person had acquired), they referred to the person as “doctor so and so” (fill in the name). Below that level, they omitted the title.

As a rule, I do not use academic titles unless there is money involved. That saves a lot of needless formality, and is more accurate.

ITT Conference on Programming Productivity & Quality (June 8-9)

The conference was in the Sheraton in New York City. It was impractical for me to stay overnight, so I drove each day (as long as two hours each way). There were a few other ATC staff at the conference (I recall Bill Paulsen, for example), perhaps a couple of hundred people altogether.

Papers were presented in side-rooms off from the auditorium. The speakers in the auditorium were solely PTC staff, plus an invited speaker (Edward Feigenbaum). In particular, I recall a succession of PTC staff who got up, one after another and introduced the next (PTC) speaker as a genius, etc., concluding with someone discussing in the vaguest possible terms a proposed system called Soma. He gave no clue regarding the system's goals or design. I asked Bill Paulsen who that person was, to warrant that type of introduction. Bill was only able to say that he was the person who translated Dijkstra's letter.

Presenting my paper was more rewarding, since the audience was fairly responsive. I have no printed program from this, but recall that Bill Curtis headed that session.

Also during June 1983, I transferred to a different department (again with Carlos, but this time reporting to Richard Wexelblat). In that department, there were people, Ruven Brooks for example, building rule-based expert systems (which probably made Feigenbaum of interest to them, as he was to others).

My initial assignment was to provide an assembler for the CAP (Cellular Array Processor) chip which Steven Morton's group was then designing. Someone had evaluated a few of the programs listed in Skordalakis's paper Meta-assemblers but found none which appeared suitable.

Softfair'83 (July 26-27)

Shortly after joining Wexelblat's group (part of a department doing internal R&D), he, Artur Urbanski and some others in his group went to a conference. There was enough money, so I went as well. (I took the train, they flew). This was

SOFTFAIR, a conference on software development tools, techniques, and alternatives
Hyatt Regency Crystal City,
Arlington, Virginia,
July 25-28, 1983
co-sponsored by IEEE Computer Society, National Bureau of Standards, ACM SIGSOFT.

While it was advertised as presenting several tools, I found the presentations too vague regarding the problems that had been solved in developing the tools (apparently, several had not reached the state of usability). As I told Artur, it seemed that the reason for presenting in SOFTFAIR was to obtain more money for research and development.

ITT Workshop (September 7-9)

PTC's replanned workshop took place in Newport, Rhode Island.

Proceedings of the Workshop on Reusability in Programming
Newport, R.I.,
September 7-9, 1983
Length 295 pages

You can probably find references to this; mainly in papers that were republished in other venues. The apparent purpose in splitting it off from the June conference was to provide a suitable publication opportunity for PTC staff.

By the way, PTC staff variously referred to their organization in print as “ITT Programming”, “Programming North America”, and “Programming Technology Center”. I am using what appears to have been their actual title (as usual, corrections citing a reliable source are welcome). The center in Stratford actually comprised more than one center, including a training center, as well as Programming Applied Technology (which I recall being told was not the same as PTC).

ITT Workshop (November 17)

In mid-November, Carlos had me come with him to Fairfield University. My understanding at the time was that it was an ITT workshop meeting (most of the attendees were from the PTC in Stratford); however it appears to have been a little more than that (a meeting of an advisory board for the university.

We were well fed (in the faculty dining room), and after lunch I was one of a half-dozen presenters. I gave a technical presentation for the meta-assembler which I had developed.

Although I presented well enough, the audience was not responsive: the lights were dim; there were fewer people than anticipated (a few left before the presentations began); one of the key members of the committee was not present (I heard someone comment that Bill Curtis had already left ITT). Another problem was the followup from the presentation. Carlos had not discussed the context beforehand. When I was done presenting, he elaborated on the possibilities of the technique, implying that there was proposed research to extend it. (I was aware of none).

Shortly after, Carlos left as well—as the deputy directory of a lab in Italy.

Later (perhaps early 1984), Ivan Cermak told us at a division meeting that the PTC was being merged into the ATC. One of the reasons given was that the PTC had overrun its budget by 50%.

GlobeCom '83 (November 28-December 1)

This was

IEEE Global Telecommunications Conference,
San Diego, California,
1675 pages.

My principal reason for writing this paper was to help make ITT 1240 more visible.
At the conference, I found that ESS 5 (the competition) was well represented, essentially dominating the session at which I presented.

Here are a few titles (found by web-searches) to help give a flavor:

My paper was in session 18:

18.2 Aspects of Network Maintenance in a Distributed Processing Environment,
T. E. Dickey and J. Mulla, ITT Advanced Technology Center,
pp 617-621

The presenters for ESS 5 were not technical staff; thus we had little to talk about. Also, at the various gatherings in the conference, I did not meet any developers. The attendees were generally managers or marketing staff.

Fortunately, my paper was along the same lines (no discussion of nuts and bolts), so I did not waste my time.

1984-1985

Like the PTC, the R&D-style group at the ATC was trimmed down. I was one of the people chosen to form a new department developing and supporting CAD tools for VLSI. The department was formed before its plans were clearly defined.

Here is a link to a paper written several months after the department was established, outlining its goals.

After the new department's first meeting, I asked what I should be doing, and was told “we need an editor”. But the person that I asked could not explain what kind of editor. Discussing this with Craig Barilla (from the R&D group working on the CAP—Cellular Array Processor—chip), he told me that they had been trying to use a VLSI layout editor (part of a tool called HCAB). Going back to the CAD people, I relayed this information, asking if they would like me to work on HCAB. They agreed.

To expand a little:

I went to work on the integration and graphics issues. There was a junior developer assigned to help me (useful as long as we were deleting code, not so useful when writing new code—he spent half his time playing hack). Enrique Abreu (in Steve Morton's group) made fixes and improvements to the hierarchical aspect.

The resulting development effort kept me busy, but I still kept developing tools, such as an Imagen (printer) previewer, futran (Fortran portability aid), and flist (file-manager).

Moving to the CAD department stopped progress on spasm, and after I advised Craig Barilla that it was unlikely to be fast enough for their needs, they ultimately chose a different product. That was early 1985, around the time that the first CAP samples came back from the fabricator.

1985-1987

Late in 1985, ITT reduced the staff at the ATC by half. Here is the short explanation for why this happened:

BTM sent a team to the ATC to acquire the technical staff from the CAD department. What they offered was shift-work (sharing a workstation around the clock with 2-3 persons per machine), for 18 months to provide a transition period. When that was done, ITT would attempt to place the returned staff in a position in the United States. Not a deal for everyone, but at least one person went. On his return, he went to DEC.

At the end of 1985, I moved on to a different development effort and was too busy to consider presentations, etc. I recall interviewing at six locations. Three were dismissed early on due to geographic preferences. Another fell by the wayside after asking about how they were organized (seeing just an outline with 400 people disqualified them). I interviewed at IDA (where Richard Wexleblat went a couple of years later). The good choice was a company which you have not heard of, taking over development of a large set of programs which supported a TCP/IP network board. In contrast, IDA was looking people with advanced degrees, who would spend most of their time writing papers. In fact, that appears to be what Wexelblat did. (I do not recall encountering any credible software developers who went there, confirming my initial impression).

This work was, by the way, not connected to an outside network. My work on ded (a new program) and lincnt (a rewrite) at that time was based on my memory of the preceding programs rather than direct reuse.

During 1986, Thomas Moriarty followed up from a discussion of flist to tell me that the remainder of the ATC (in Stratford) was in the process of being sold to Alcatel. Reportedly (seen here and here) the process was messy.

In 1987, I left that development position because the people in charge (the vice president who hired me and the board's hardware designer) both left. They had come to this company about a year before me, and during that time, it was taken over by another company (with cash). The vice president announced in April that he was planning to leave, that he had agreed to stay on after the takeover for this amount of time. The following evening (Friday), the other developer came in around 11:30pm and copied all of the project's files to a tape. I found this had happened on Monday morning by using ded to review the access times for files (to remind me where I was on Friday) I advised the manager, who confronted him. (I was told later that he said he was just doing a backup). Notwithstanding that, he stayed on a few months after the manager left, leaving a few weeks before the hardware engineer.

That left me and a marketing person (in mid-October). Luckily, the Software Productivity Consortium (SPC) was hiring (and for about four years, they did software development).

Before leaving for SPC, I worked with the hardware engineer who took over the project, to ensure that our documentation was up to date, and assisting him in resolving a problem with the board's design.

1989

During the first year that I was with the Software Productivity Consortium (SPC), I designed/developed one of the first set of deliverables to our member companies. This was a prototype application which demonstrated how requirements documents could be automatically linked together, allowing the user to navigate between the different aspects of a requirement (design, testing, etc.).

Brian Nejmeh set out to write a conference paper on the topic. After some time, he asked for my comments. Reading his draft, I could see that the presentation was rather muddled—no clear path through the verbiage. I suggested some changes, giving him a modified copy which deleted parts, moved other parts and filled in statements which were not obvious. He added me as a co-author (I do not recall seeing the final paper).

Traceability Technology at the Software Productivity Consortium
Brian A. Nejmeh, Thomas E. Dickey, Steven P. Wartik,
IFIP Congress 1989: pages 981-984

That was presented (by Nejmeh or Wartik) in San Francisco at the end of August 1989. I was not much interested in going; the previous year Nejmeh said there was money for conferences and I went to the Summer USENIX Technical Conference (June 20-24 1988) also in San Francisco. The only interesting paper was the one on spiff. I spent the rest of my time walking across the city (my time was well spent). Thereafter, if asked about going to a conference, I would reply that I preferred just getting the proceedings.

Nejmeh and Wartik worked on other papers, but this one found only one admirer (Ramesh Balasubramaniam).

Most of Nejmeh's and Wartik's other papers were either written in the same period (late 1980s to early 1990s) or followups from one of those. In contrast, though I still am associated with some programs from that era, most of my work is newer and ongoing.

Because Nejmeh was moving on to some more interesting endeavor, he apparently turned completion of this over to Wartik (who came in around the end of 1989). I worked with Wartik on followup work for the traceability project, as well as setting up an early version of TAE Plus before I moved to the Dynamics Assessment Toolset (see the slides mentioning DAT from RICIS '88) project. In between (Nejmeh and DAT), Warktik attempted to get the four people reporting to him to develop a further traceability prototype. However, two were non-productive (one viewed SPC as an extended vacation, while the other had managed to acquire a PhD in computer science without learning to program). The former eventually melted away, back to his member company. The other left because of conflict of interest (publishing work he had done for SPC with his copyright notice and his one-man consulting company cited as owner). Getting the productive member of the team to produce was assigned as my responsibility by Wartik (the team lead), who did none of the development.

While there were a few cases of inappropriate copying (I sent the security officer after one, who was copying all of the files from my workstation as he was preparing to leave for another company), SPC staff were for the most part pretty well behaved. I could have written (or co-written) a paper or two based on the work that I was doing. However, I did not seriously consider this. SPC produced reports. Around the middle of my tenure there, they got interested in check-lists (and associated work-flow). It took 18 signatures to get a document out the door (not bad with fewer than 200 people). So I put that thought out of my mind, reasoning that any paper that I might contemplate would require just as much overhead.

Instead, I wrote user manuals for the programs I developed at SPC. I found that about a third of the problems surfaced in documenting. That is, in writing a description, I realized that I ought to check it, and found errors of omission or functionality.

After joining DAT, predictably, I wrote another large application on that project (an X Window application which presented results from DAT in a variety of formats). Judging by this report, Wartik continued working in the requirements area.

I worked on the second version of DAT. Not much was published from that, for the reason that the project failed to meet its scheduling objectives. A few of the team members decided, about a third of the way through the schedule, that they had a better idea of what to implement. They bypassed the team leader, getting upper manager to agree to the change in direction. However, they did not obtain a waiver for the scheduling change, and the resulting program was two-three months late (on a schedule constrained to be less than a year). Seeing this coming, I dug in my heels and resisted the temptation to make the delay worse. I had the impression that of the ten developers on the project, I was the only one to deliver what I had agreed to, on the original schedule. The project's team lead left.

The “better idea” was undoubtedly done for all of the best reasons, but it gave the management a bad experience. It was the last large (multi-person) development effort done at SPC that I was aware of.

Still, it was almost two years before I left (at the end of winter, 1994). I worked on prototypes whose scope was less ambitious (and I did all of the development work on those). Helping to get me moving was my last review (noting that my manager and I were good friends, even after this). He wrote it out as three points (quoting from memory):

Three-four months later, SPC reduced staff by about ⅛ (taking care to first fire someone who was not working the hours that he charged).

Fortunately, I had a friend from SPC—the person who had been the team lead for DAT. He knew someone who needed my skills.

In addition to my real work, I was developing ded and other programs during this time period (1985-1994). At this point, it is perhaps a good idea to review how I started this:

Coming into the next company, I advised them up front that I had programs which should be excluded from my employee rights assignment. They agreed, and the resulting piece of paper said that I am “sole proprietor” of the programs which I distribute on my website. In discussion, the points agreed upon was that I made no money from these (which was the big issue for potential conflict of interest), and that I did the development using my own resources. Working through the implications of that, I took additional care to avoid conflict of interest by not mentioning who pays me. This was (and is) a distinction from people who made newsgroup postings with the disclaimer that their posting does not express the views of big corporation XYZ.

I had “bought my own soapbox” (and the entry costs have declined enough to completely obviate a need for disclaimers of the type just mentioned), and to a large degree these activities are independent of whoever my employer happens to be during the intervening years. This is not the same as Heinlein's story about the man who bought his own cannon. Rather, it has provided me with a way to develop—and publish results—work whose duration and visibility would not be feasible in the paid work which I do.

Incidentally, none of the companies for which I used to work is in business any longer (though some trademarks were transferred to other companies). Even pictures of the large complexes are lacking.

Reports and manuals

Papers (good ones anyway) are not written in a vacuum.

1973

As an engineering student, I began by writing reports. But writing reports was not that simple, because time was always limited. That led to my discarding unnecessary parts of the college experience (such as classes and grades), to do the work.

Initially, there were few reports. That changed:

The report for the senior project, though lengthy, had little impact. Due to the shift in curriculum (from two semesters to 4-1-4), the amount of time was reduced. We did half of the project during the first semester and the remaining half in January. Writing the report consumed the last weekend of January (using typewriters in the school newspaper office to produce mimeographed copies of the report). Before 4-1-4, senior projects would be presented during Engineering Week. With 4-1-4, we finished the senior project by submitting the report.

The school yearbook did have pictures showing our project, so some attention was given by others.

1974

In graduate school, it took a while to get started, but I wrote reports. During the first year, I was supported by an NSF fellowship. That was good only for one year. After that, I was expected to find support by working on a funded project with one of the faculty.

I was told to talk to Lavi and Neuman. They had an opening in their project (another student, Jack MacDonald had just left to serve in the military). Meeting with them in Lavi's office, Lavi said

We'd like to know about microprocessors.

That sounds overly general. Lavi and Neuman had been working with GATF (Graphic Arts Technical Foundation) to improve procedures. At that time, the Intel 8080 had just been announced. It might be possible to use a microprocessor in a print shop to automate some of the improved procedures. There were many questions to answer, e.g., would a microprocessor even work in the (relatively) hostile environment of a print shop, and what sort of tasks could be dealt with using a microprocessor.

I proposed initially getting some experience with developing a simple system for constructing continuous control systems, and then developing tools for studying microprocessors. That was agreeable to Lavi and Neuman, so I proceeded in that direction.

Not long after, Lavi went off into a different project (OTEC, with Clarence Zener) and left Neuman in charge of his students. There were three: I, Frank Allmendinger and Bernie (I cannot recall the spelling of his last name). The other two left without completing the degree. I was able to finish, but without assistance from Neuman, whose interests did not intersect mine.

In the first phase, I developed CSM, a block-diagram system (having in mind some related work I had seen as an undergraduate, as well as electronic components called RTMs which were used for labs in graduate school). I began development on a PDP-11/20 owned by the department, and later (early 1975) moved to the newly acquired PDP-11's running with CAPS-11 (cassettes) and RT-11 (RK05 disks). Gary Leive and I were the main users. Because there were perhaps another dozen students who used these single-user systems, they were in use at all hours of the day.

Paper tape is one thing, a hard-disk is another. Disks hold more, cost more. Neuman agreed to purchase one for my project, and stopped there. Over the next few years, I purchased four more, ending up with three copies of the sources, two copies of RT-11 with my programs. With fewer disks, I would have lost everything on more than one occasion.

After CSM, I developed cross-assemblers and simulators for all of the microprocessors for which I could get enough information. Because I used a modular approach, only about 5% of the cross-assembler and 20% of the simulator would be customized for each microprocessor. As a result, early in 1975 my development efforts were getting some interest from others. One of the faculty (Ron Krutz) wanted to use the programs in a course.

There was a problem: I had written no documentation. I was willing to do this, but (thinking back to my senior project) was not eager to spend weeks typing in a manual which would become a distraction. Others conferred, and Gary Leive told me that Ron Krutz and Dan Siewiorek had agreed to have me write the manuals using Gary Leive's PDP-10 account.

I worked on these manuals during 1975-1976, completing the requested initial version in a few weeks, and revising them a few times to reflect improvements which I made. However –

That fall, Neuman enlisted my assistance in writing proposals (for more funding). In one, I resurrected the prototype of a computer which Jack MacDonald had developed, as a simulation (and wrote an assembler for that). In another, I put together a list of equipment (and costs). Neuman's proposals were unsuccessful, and he told me that there would be no more money. This was not immediate, but I understood that it would be within the coming year.

That fall also was the end of my taking graduate courses. During the first two years of graduate school, I had taken a variety of courses. Some such as Duffin's linear programming, Simon's cognitive processing and Newell's computer science “immigration” course, were prompted by Lavi who commented that they were “popes in their field” while others (such as the statistics courses) were based on department recommendations. Regarding the statistics courses, Bernie noticed that we had enough credits in those to obtain a masters' in statistics, but was told by Neuman to not do that.

My final graduate course was independent study. Another student had suggested that it might be possible to adapt my macro assembler module to generate a wiring list for RTMs. I did this project with Dan Siewiorek as the faculty contact, in part because I was curious how that would work because of the large number of students who had gotten incompletes from his courses. I completed my project, and wrote a report (but Siewiorek made no comments or other response). Neuman disapproved of the whole affair.

1976

In 1976, the story gets more complicated:

During the spring, Neuman (with my assistance) put together a paper describing CSM and the cross-assemblers and simulators which I had developed. In retrospect, the paper is a little bizarre, since the discussion of control systems (with equations) is not connected to the development tools.

That was Neuman's goal however: to publish a paper. My goal was to consolidate my work into a form which would result in a degree.

Cross-assemblers and simulators are suitable for master's projects. I developed enough tools as a graduate student for several masters degrees. To achieve my goal, I had to go beyond that, by determining a suitable topic for the dissertation, and then pass an oral examination to become a candidate.

I proposed using the tools which I had developed to study the instruction sets of several microprocessors to gauge their suitability for use in process control applications. How I would do that was as yet undetermined, but with my written proposal in hand, proceeded into the candidacy with four members of the faculty:

Lavi and Neuman of course were my advisors. John Grason was the lecturer for the RTM course. Wolfgang was in the mechanical engineering department, with a PDP-11/45 which he was using to study control systems (i.e., the Computer Based Automation Laboratory “CBAL”).

With that done, I continued working even harder to attempt to finish my research before funding would run out.

Along the way, I continued work on the manuals. I did all of this work at night, because (a) it was easier to get access to the PDP-10s and (b) because the machines were funded by a Navy contract for the computer science department, others were not supposed to be using them. I kept this in mind, working from midnight until 7am.

However, one morning I was late, leaving around 7:30am. Just as I was logging off, in came a typist from the computer science department, who saw me, and reacted much as one might expect at seeing a rat in a fancy restaurant.

As a result, Siewiorek immediately disabled my access to the PDP-10s. This was in June. I spent an hour in a hot hallway pleading with him to have my files put on a tape rather than just being deleted.

Moving on past that, I resolved to not rely upon Siewiorek for anything in the future. Going back to my department's PDP-11, I began writing my own text formatter. I used that when I wrote the dissertation.

Ron Krutz was able to use the revised manual from my work in 1976, according to Carlos. One day, Carlos told me that I had missed all of the excitement. According to Carlos,

I still have a copy of the manual – without Neuman's change. Neuman did not mention this episode to me.

Around this time, Carlos Baradello suggested to Wolfgang Sauer that it would be helpful to all of us if I were to use Wolfgang's PDP-11 in exchange for helping them maintain that computer. Again, this was for off-hours work, at night and on weekends. This arrangement lasted for about three years (ending after both Carlos and Wolfgang had left, in 1978).

My time limit for funding was more definite than the expected time of completion of the research. I started work in the Power Electronics Laboratory at the R&D center late in August 1976. At that time, John Rosa was the department manager; Laszlo Gyugyi was my supervisor.

My assignment was to take over and improve the computer simulation which had been developed by the “two Jims” (James Vine and Jim Koos). This was initially about 2500 lines of Fortran, which I tripled in the process of providing Laszlo with nicer plots for the proposals which he made, along with changes to the simulated electrical system.

Laszlo was pleased that I was able to do these things with very little supervision.

After I'd been at the R&D center about a year, Laszlo came by to tell me

The way to get ahead around here is to write reports and memos.

We discussed it further. The essential point was that reports were more noticed, memos less so. Over the next 4 years I wrote 45 reports and memos. The R&D center had a monthly newsletter listing reports and memos. My work was usually there.

Laszlo generally just signed the report or memo and said nothing. On one occasion he did comment, a little flustered after reading a report which I wrote about “equate” (a block-structured equation plotter):

The people who give us money aren't going to understand this stuff.

I promised to be more careful about which were reports versus memos.

At the same time, I continued working on my research, developing a computer model of microprocessor instruction sets, from which I might calculate a measure of their relative complexity. As far as the university was concerned, I was in absentia while working on my dissertation (and paying $500 a semester for this). Actually, I was working 30-40 hours at the university on the weekends for almost two years, before switching to two evenings a week and Saturday (all day) in mid-1978.

Being in absentia meant that each semester Neuman would mark my resulting grade as an incomplete. This meant that I could not get my employer to reimburse that cost. Neuman had no other interaction with me during this period.

There were distractions which cost time as I developed solutions:

Toward the end of that three-year period, I had additional problems to contend with. The PDP-11/45 in CBAL had hardware problems, and would malfunction if the lab became too warm (i.e., warm enough that I did not need a sweater). Finally in the spring of 1979, its power supply died. Replacing it would take $900. I discussed this with Art Murphy, offering to pay for that. He refused that, which left me moving back to the computer owned by my own department.

To do that move required more work on my part because I relied upon a newer version of the Fortran compiler – which was configured to rely upon the extended instruction set. I solved the problem by writing an emulator for those instructions while on my lunch break at the R&D center.

With one distraction or another, I completed my computer model during 1979, and was able to explore how good (or bad) my complexity measure was. It turned out to be both:

Having the results to discuss, I quickly wrote the dissertation and submitted it to Neuman to review.

Time passed...

Actually, submitting the dissertation meant that things were just starting to get interesting. Neuman (as with the manuals I gave him in 1975) was in no hurry to give feedback on the initial draft. There were a handful of grammatical tweaks, but no comments. I called him on the telephone once a week to chat and find out his progress. He had none.

1980

Like 1976, 1980 was a point at which my two stories (university and R&D center) are intertwined:

Although Neuman was unresponsive, there was little that I could do about it. This was a period of transition for the department, with Angel Jordan leaving. The department history notes:

Angel Jordan becomes the dean of engineering in 1979.
Floyd Humphrey becomes our sixth department head in 1980.

At my first opportunity, I paid a visit to the (new) department head, Floyd Humphrey. On explaining my concern, Floyd responded:

I'm afraid there's nothing that I can do unless it reaches the state of a disaster.

which I found unhelpful.

Meanwhile (early 1980) at the R&D center, things were proceeding.

I was asked to work with Alberto Abbondanti on a project which would use an 8086 microprocessor in a power converter. This would use an Intel development system, which I would have to learn about. Just as things were starting on that, there was a reorganization of the division (which did not affect me, personally). In that lull of three weeks, I wrote a better text editor for that system, and started writing utility programs to help with the end goal (supporting the power converter project).

All of that activity, of course, would be documented in research memos. Over the previous three years, I found that getting reports and memos typed was a problem, because the secretary was too busy with reports for others (such as Laszlo). Because of my work with the Univac, I initially improved that using the @doc program, along with a printing terminal. That left only the title page to be done manually. Later in 1980, I worked with Alberto to produce the report for this project using the DPS feature on the Univac system.

In the meantime, there were other things to do. The reorganization meant that the engineering division was no longer part of the R&D center, but part of the defense division in Baltimore. In practice (at first), that had little effect on what I was doing. Around the same time (perhaps connected to the reorganization), John Rosa retired and Laszlo was promoted to replace him. That left a vacancy, which Laszlo filled with one of his friends from another group. Laszlo's friends were either Hungarian (his origin) or British (his school).

My new supervisor was Miklos Sarkozi who, it happens, had been supervising some of the people who had worked in the lab at the university. They had developed a microprocessor application. Miklos had the resulting computer listing on top of his office bookcase, and was very proud of it. I took a look when he was away, and saw that it was about 200 pages, but was printed with the assembly language (including macros) expanded to one byte per line. Printed normally, it would have been about 25 pages.

Miklos had little to do with the project on which I was working. Alberto was the principal investigator on the contract, and did most of the paperwork. I did most of the development. Peter Wood was on that contract briefly, according to one of the reports that I have retained.

However, Alberto was excitable. I have mentioned one instance in the discussion of DPS. In another instance, Alberto was expressing his disagreement over the way I had organized the monitor program. Rather than use the in-circuit emulator which he had planned, I pointed out that the iSBC 86/12 board provided a dual-port RAM, which would let us dispense with ICE and simply develop the controller application with the ISIS-II system plugged into one port. I developed a simple monitor, repeatedly displaying the state information of the controller. That was good. Alberto accepted that. What Alberto did not like was that I was storing the monitor's copy of the state information with one bit per flag, rather than storing one byte per flag. That was important to the design, because the amount of memory was very limited. I pointed that out, and in response to Alberto saying that he did not like it because he wanted to examine memory, followed up by pointing out that he was only going to be able to see that memory via the program which was reading the shared memory.

All of this was distracting others, including Miklos because his office was midway between Alberto's and mine. Miklos asked what was going on. I replied

We are having a philosophical discussion about the nature of computer software.

to which he responded

Oh. Mind if I listen in?

and on getting agreement, listened to the argument for a few seconds before pointing at Alberto, saying “He's right” and then leaving.

With that victory, Alberto was confident of support from Miklos.

The progress of my dissertation picked up a little in the spring. Although I had submitted it in September and seen little response from Neuman, I had not stopped spending time at the university. One Saturday early in May, I was waiting at the bus stop next to Hillman library when I saw Jordan. He asked how I was doing. I replied that I had submitted my dissertation to Dr. Neuman, and Jordan nodded approval. I finished by saying that after eight months, Neuman was only halfway through reading it. That got a glare from Jordan, who commented “We'll see about that” and we parted.

Neuman finished reading (and nitpicking) by late May. That began a new set of problems. The people who had been on my candidacy committee were (except for Neuman) not available:

As a result, we needed a new committee. Neuman said that he wanted Dan Siewiorek and Don Thomas, plus someone from the Statistics department. The latter was not a problem. The former were a problem, because most of my interaction with them had been poor. This page only mentions a small part of those interactions. I objected, reminding Neuman of that. He disagreed, saying that my concern was mistaken. I disagreed as well, saying that I could probably handle either of the two, but putting them together they would be certain to make trouble. I suggested Ron Krutz, reminding Neuman that my relationship with Krutz had been amicable. Neuman of course had a different viewpoint. Neuman was not inclined to negotiate on this demand, since the dissertation was about computers. Viewing Siewiorek as having more potential for trouble, I proposed Mario Barbacci as an alternative. That was at least a neutral choice because I had no interaction with him. The pool of computer engineering faculty provided no other choices.

I gave draft copies of the dissertation to Wen Chen (statistics), Don Thomas and Mario Barbacci. Checking a week later, I asked Mario if he had any questions. He replied, no, adding that I write very clearly.

In July, I met with the committee:

As a result, we spent a couple of hours in July repeating ourselves. Now, if I had had more leverage with Neuman, this would not have happened. In retrospect, Mario likely discussed this with Thomas at length before the presentation, and all three (Siewiorek, Thomas, Barbacci) had worked together for several years. Siewiorek was the advisor both of the other two (see mcCluskey tree).

However, the committee decision has to be unanimous. Chen was unimpressed by Thomas's comments about the statistical design. Barbacci made no arguments, either, which gained acceptance by Chen. Neuman of course had little to say, but had little to agree with from either.

A deadlocked committee is a matter for the department head to resolve. At that moment, Floyd Humphrey was in China, and would not return for a few weeks. After returning, he had things to catch up with.

I met with Humphrey in September. Probably forgetting our previous conversation he made some remarks about the situation, to the effect that nothing could be done (i.e., that the topic was not acceptable). I had come prepared however, bringing a copy of my thesis proposal. Showing it to Humphrey, I said

I did what I said I was going to do.

Humphrey saw immediately that it was not going to be so easy to get rid of me. He told me that he had some more investigation to do.

We met again a few weeks later. This time, he had better news:

I contacted Dr. Lavi, and started the process.

Around the same time, the scene switches to the R&D center.

In this episode, the engineering division (which had reorganized early in 1980 was purchasing a VAX 11/780. Each of the departments would contribute toward the costs.

The people who would administer (and control) the new computer were the group which Miklos had worked with before. I expected that they would treat this as they had the lab at the university, and treat it as their personal playground. This is what actually happened. But I tried to improve the situation (without success).

In the Power Electronics Laboratory, we had at least three engineers who used a teletype (with paper tape) next to the secretary, working with a time-shared system down in Rockville, using BASIC for calculations. Seeing that the VAX/VMS system had BASIC, it occurred to me that we could get something for the department's share of costs for the VAX by moving those people onto the VAX.

I suggested this to Miklos, and followed up a couple of times over the next few weeks. Miklos was having none of that (with him, it was good politics to provide for the people he had worked with), and after a couple of repetitions responded that we were not interested in computers, and that I

should go out into the lab and turn some dials and smell some smoke

He concluded with

Software people are naturally subservient to hardware people because they never originate research problems.

Of course I could not leave until disentangling from the university, but I was done with Miklos at that point.

Continuing with Lavi...

I began meeting with Lavi on Saturdays. At our first meeting, he introduced me to his wife, explaining my presence as like (perhaps Sood or Schonbach – I do not recall), that Neuman had done it again. “Oh dear” was her response.

Lavi commented at the outset “We're going to rewrite this so that it offends nobody”, and instructed me to write an initial chapter, giving an outline of what should be in it. I had brought a copy of my dissertation with me; Lavi was not yet interested in looking at it.

The next two Saturdays went the same way, with a new chapter and ignoring the dissertation which I had written. At that point, he was willing to look at what I had already written. On reading my fourth chapter, he was surprised, asking “What's this?” I told him that it was what I wrote. Lavi saw no reason for me to write further chapters, but reviewed the content of the remainder of the dissertation. Like Neuman, Lavi did not like the caveats, and (though I had toned them down a little to appease Neuman), told me to just take them out. That was the wrong move of course, but I had no leverage.

All of this revising and rewriting took time, lasting through the winter. Late in 1980, a new problem arose with the PDP-11 which I was using for working on my dissertation (and producing the drafts for editing). This was the survivor of a pair of computers which the department had bought in 1975, and was in the upper story of the department's building. Call it an attic. Someone had a friend who wanted the computer, and was going to take it away. The underlying problem was that a computer powerful enough to do my work would at that time cost about a year's salary. Times have changed, computers are less costly. At the time, I used computers that cost me nothing, but someone had to pay for those. Oddly enough, I recall reading in the school newspaper that the university began providing accounts on the TOPS-20 system while I was working on my dissertation which I might have used (with a different advisor than Neuman).

A solution to this new problem happened by chance. My wife was working in John Szedon's group at the R&D center. A member of the group (Bill Biter) was putting together a lab with lots of equipment. It would have HP equipment and a computer. Asked if I could use that, I explained that there were lots of different types of computers and that I would have to have permission, etc. It turned out that the computer would be a MINC-11 (running a newer version of RT-11) and that permission could be gotten. For once, there was a simple solution.

Dan Klein helped me by copying one of my RK05 disks to a 9-track tape. Because I was in a hurry, I went directly to the 3M distributor to get my tape. The people at Graham and Associates had thought I was a company because of all of the disks I had bought. After Dan came back with the tape, I went to DEC's support office in Monroeville, to use their PDP-11/70 to copy it to floppy disks. The MINC-11 used only floppies.

After that point, I was no longer using the RK05 disks. I kept those in a locker in the department's lab, with a note taped to the door with my name and phone number. I used that locker from 1975 to early 1981. After migrating to the MINC-11, I still made frequent visits to the university. On one occasion, on entering the lab, I saw that the locker had been demolished (since the previous week), and someone was constructing desks in that area. I asked, was told that the person running the lab had the disks. That person was less than forthcoming with an explanation, conceding that he had the disks, but denying that there had been any contact information available. The disks were on a shelf, no longer in their boxes (and rather dirty due to the construction). Discussing this with another person who happened by, I was advised that the robotics team might be able to use them. I recalled that Jack MacDonald had returned to the university and was working there – but he was not available. So I went directly to the robotics team with my four disks. They were willing to take them (and pay me half the cost), and reformatted the disks. Neuman's disk was left on the shelf for his possible use.

I had a different plan for the disks, which was no longer possible. At that time, I had no automobile, and got to the university by bus, but rented an automobile periodically. My plan was to take those disks to DEC's support office and make several copies on 9-track tape for possible later use.

That was the last (but not the first) problem which I had with that lab. A quote from Ian Fleming (Goldfinger, 1959) applies:

“Mr Bond, they have a saying in Chicago: ‘Once is happenstance. Twice is coincidence. The third time it's enemy action’.”

Finishing the year with Alberto...

Late in 1980, probably related to the reorganization, the management decreed that each engineering department had an increased quota of patent disclosures.

The department copying machine was next to the door of my office. I happened to notice Alberto making a copy for a patent disclosure. Because it had an illustration, I recognized it as the fireman's pole scheme which I had devised for the project on which we were working. That was part of the report which we had written. Alberto saw that I had seen this, and said nothing. He knew that my complaining would have done no good. Later (probably the following year), he revised the disclosure, changing the table from a chain of no-ops to a groups of instructions with larger granularity to make the relationship with the report less apparent. That was filed in 1982:

A microprocessor-based solid state AC-DC converter system makes use of the microprocessor facility to implement sequential thyristor firing at selected delay angles. A first timer at the AC line fundamental frequency supplies to the microprocessor a numerical master ramp count, from which individual ramp counts are calculated which relate to the individual thyristors to be fired in sequence. From such an individual ramp count by comparison with a delay angle reference count the microprocessor calculates the number of units of time needed until zero count on the individual ramp. A second timer is preset at an initial count value equal to such calculated number of units of time and the second timer is run to count-down. The thyristor next to be fired is triggered when zero count occurs.

1981

During 1981, I concluded my involvement with both university and the R&D center. I continued writing reports and manuals, of course.

For the first half of the year, the two stories are concurrent. The university story ends earlier, so I will focus on that.

In preparing for the presentation of the revised dissertation, there were still the same problems, updated:

The committee change was simple (from my viewpoint). Lavi agreed to asking Ron Krutz if he would be the fourth member. I asked, he accepted. There was still a problem there.

For final copies, I had to produce camera-ready printouts. Discussing this with Gary Leive, he did not see the problem. I explained that I planned to include the entire model program, as well as the benchmark programs and the microprocessor descriptions as appendices. Also, due to the amount of paper that would involve, I wanted to produce it as two-sided prints (just like a book). Gary did not think any of that was necessary, commenting that the computer science guys do not publish a single line of code.

Perhaps. But I had read several dissertations, to gauge how well mine compared (concluding that I was somewhere in the middle). During early 1981, I also read Don Thomas's dissertation. There were a few things that caught my eye:

I printed the draft copies on the line printer connected to the Unix system at the university, and the final copies using a daisy wheel printer connected to the MINC-11 machine at the R&D center. For the latter, I wrote a program which could handle underlining efficiently (see unover).

The problem which arose in my second presentation was due to the changes which Neuman and Lavi had urged upon me. Reducing or removing the caveats about experiment size made Wen Chen uneasy, but made Ron Krutz upset. I acknowledged that as a deficiency, but did not explain to him how that came about. At the same time, Floyd Humphrey was kept in mind by me and Lavi: there would be no more extensions. Humphrey had told Gary Leive the same thing, though I suspected that there was some flexibility there.

Rather than spar at each other for another hour, I was released by Lavi to await my fate outside in the hall. Another hour passed. Then the door opened and Ron Krutz stormed out, down the hall and left the building. He was furious, but my dissertation had been accepted.

In summary, if my advice on committee and caveats had been heeded, none of that extra work would have been necessary.

After the presentation, my remaining work was to produce the camera-ready copies, and have provide a bound copy of the dissertation to the university library (two copies), one for the microfilm archives, and one each for the members of the committee. I produced two versions: one without the appendices (for the committee, I recall) and one with the appendices. The difference is 4-5 hundred pages. In one of my visits to the electrical engineering department office to deal with this, I was told that Wen Chen had died. His department has a web page on the topic. None of the others from the first committee remain, but they lasted longer.

The R&D center is likewise gone, but in 1981 it occupied my thoughts.

In 1980, I worked on a different project, but in 1981, I returned to working on the computer simulation. Instead of helping Laszlo to prepare proposals, this was to help with a problem which came after the system had been delivered.

A static var generator (SVG) is used to reduce problems caused by poorly behaved electrical loads. For the non-engineer reader, this helps prevent your lights from flickering when the factory down the road turns things on and off. The system had been sold to a power utility with specific performance guarantees. The power utility did their own measurements and found that the performance fell short by about five times.

Due to the complexity of the SVG (with three phases of voltage and 33 capacitors used to filter out frequencies, and with repetitively connecting/disconnecting these components) it was not possible to analyze the system and predict its performance. Computer simulation could show results for typical loads.

The corporation provided money to investigate the discrepancy. Derek Paice managed the effort. Gene Strycula also was involved. By some agreement between Laszlo and Miklos, I was to work with Derek and Gene on the investigation. They chose to proceed by experimenting with the filter design, creating simulated waveforms and then using that data to drive a D/A converter in the lab to see the result.

Most of the time and effort was spent in setting up the simulation on the Univac mainframe and getting the data into the lab. I modified the simulation to create a data file, and asked the computer center staff to write it to a floppy disk, then took that to a different machine to write to another floppy disk, and then took that to the lab, set up the D/A converter. Finally I was ready to show Gene the result. Then he spent an hour choosing new numbers to try again. Think of that process as rolling the dice again.

We made no progress, slowly. The computer center operator would wait until a few minutes before noon the next day before writing the floppy disk. The reason for that was a long-term grudge held against us because I was maintaining the computer simulation rather than them. Jim Koos was easy to deal with, but his supervisor (Brenda Kagle) was not. The person who handled the floppy disk requests reported to Kagle.

Because that did not occupy all of my time, I worked on memos for the documentation aids which I had developed. I gave those to Miklos for review, who put them on his bookcase and ignored them:

Miklos was not involved in any of that, except for the part where a different developer (also reporting to Brenda Kagle) produced a one-line attribution for his manual describing the printing utility which I wrote.

While this investigation was going on, I completed the changes for my dissertation which Lavi directed, and I presented it. After that, my involvement with the university wound down, and I began looking for new employment. That also went slowly, with only a few responses. Sometime in August, I mentioned this to Carlos, who suggested that I come and work with him at ITT. I was reluctant to do this, commenting that people hiring their friends did not work well, in reference to my ongoing situation with Laszlo and Miklos. Carlos's response was that was what friends were for; I responded that I would think about it.

I was also concerned with the lack of progress on the SVG investigation, but had no solution for that. The basic problem was that this was a 99th-order nonlinear system: 3 phases, each with 11 filters each with 3 reactive components, with each of the 3 phases being connected and disconnected during each cycle of the input power. You can simulate that all you want, but you cannot easily predict the spectrum of the output power. Gene Strycula gave no indication that he recognized the impossibility of solving the problem.

Gene Strycula and Gene Rodgers occupied the office next to mine during the five years that I was at the R&D center. Strycula had completed a PhD in 1974, and was fully vested a few years later (after I joined). Vesting (in the retirement plan) took ten years. Strycula told me that on completing the degree, he lost his purpose for a while (and commented that Laszlo had a similar experience). Because I told him about my experiences with the university, he also commented that he had heard Laszlo shouting into the telephone on receiving a call from the university where they both had gotten a master's degree. Some experiences are not that unique.

Strycula had other things to say:

Laszlo and Miklos heard none of that. But Laszlo had commented a few times that computers were a very narrow specialty. After Miklos became my supervisor, both made those comments. There are two ways to look at this: computers in power-electronics are a niche, or just generally. Because they never qualified their comments, it was apparent that they meant the latter. In that case, they were out of touch with the world. At the time, the IEEE Computer Society had 22% of the members, while the Power Engineering Society had less than half that many members. Since then, the ratio has increased: the Computer Society accounts for 80% of the IEEE members, with the Power & Energy Society unchanged.

In September 1981, I had my first performance review, with Miklos. That was 18 months since my previous review, with Laszlo. In contrast to Laszlo's comments, Miklos had only negative things to say. Laszlo sat with us to observe, but had nothing to say. There were two parts:

While Miklos certainly could have done his homework (i.e., asking for specifics in the form of a transcript), I saw no reason to educate him. On my part, I did get a copy of Peter Wood's book. I was disappointed:

In preparing this web page, I looked for a copy of the book so that I could be more specific. The Internet Archive had a copy, which I inspected. However its copy did not have the same opening page. The word “obvious” did not appear. By searching for “obvious” and ”trivial” I found those occurred more than 30 and 10 times respectively in the book. Looking at its date of publication, and recalling an overheard conversation between Peter Wood and Laszlo, I see an explanation. I heard Peter Wood telling Laszlo how much he had spent to have a book printed (e.g., in Hong Kong). Ultimately this would be published by VNR (Van Nostrand Reinhold), and a competent technical editor would clean it up. It appears that I got Peter Wood's self-published book.

I discussed the review with Carlos, who arranged to have ITT make an offer. With that in hand, I wrote a summary of the situation in which I said that I was not going to work with Miklos any longer, due to his interference. As an alternative, I suggested that if Laszlo did not want to lose the expertise which I had acquired in the computer simulation, that he could assist in helping me move to a different part of the R&D organization.

When I gave that sheet of paper to Laszlo, he glanced at it, and responded that he couldn't take this seriously, and then added

I could only take this seriously if you were going to be a manager, and you're in no danger of that.

I responded that I was going to go and look at houses (near the ITT facility of course). I found a house within walking distance, and on my return to Pittsburgh, gave notice. I left, because it was apparent that I was working in the wrong area if my employer had no end goal in mind which required my skills.

The acknowledgements section of Understanding FACTS bears comment:

Dr. Gyugyi would like to acknowledge his past and present colleagues at the Westinghouse Science & Technology Center, who significantly contributed to the FACTS and related power electronics technology development. In the 1960s and 1970s, John Rosa, Brian R. Pelly, and the late Peter Wood were part of the early development efforts on circuit concepts, along with Eric Stacey who joined in these development efforts. Subsequently, Michael Brennen, Frank Cibulka, Mark Gernhardt, Ronald Pape, and Miklos Sarkozi were the core members of the technical team that developed the Static Var Compensator.

None of those worked on computer simulation or analysis.

A few months after I left, someone from the R&D center called me at ITT, and asked if it was okay for me to answer questions about those programs. I had no problem with that, but heard nothing more. I am curious how Laszlo and his friends got around the unsolvable problem, but note that they continued working in the same narrow specialty for another twenty years.

1982

ITT used computers (see discussion). While on the 1240 project, I developed about 250 scripts (including some which used special-purpose assembly language filters), and documented about 160 of those. The script documentation used the extensible XEDIT help feature.

Unlike the R&D center, there was no culture of reports and memos, but there was a way to document things so that the users of my programs could get the required information.

After moving away from the 1240 project, I wrote manuals for the other programs which I developed. Manuals, it seems, are more widely read than reports.

Acknowledgements

Besides my published artifacts (programs, documentation and mailing archives), some of my work is recognized by others in the community. This is a list, ordered by date, of books where my name appears in the author's acknowledgements. That is, I contributed in some way to the book.

Citations

Citing my Work

“Citations” differ from acknowledgements.
I did not actively contribute to the works where the citations are made.
Their respective authors provide the citation to show that they were using my work.

Here are a few which relate to my role as the developer/maintainer of various programs:

Citing my Words...

Those are citations of my work. Papers are a different matter.

The (two-page, counting the table) letter regarding Sackman and the 28:1 ratio has gotten the most citations. Some of the more interesting comments were found via Microsoft Academic (defunct since 2021). Google Scholar found the majority of the list shown here (which I have ordered by date, and filled in details). The list is provided to demonstrate (to myself, at any rate) that the letter has become a lasting part of the relevant technical literature.

  1. Predicting performance in computer programming courses
    by Richard J. Koubeka, William K. LeBoldb and, Gavriel Salvendya,
    Behaviour & Information Technology
    Volume 4, Issue 2, pages 113-129, 1985
  2. The impact of individual differences in programmers
    Bill Curtis, pages 279-294
    in Working with computers: Theory versus outcome,
    G.C. van der Veer et al., eds. San Diego, California,
    Academic Press 1988
  3. Productivity Impacts of Software Complexity and Developer Experience
    by Geoffrey K. Gill and Chris F. Kemerer,
    MIT Sloan School of Management, Cambridge, MA,
    January 1990.
  4. A Model to Evaluate Variables Impacting the Productivity of Software Maintenance Projects
    by Rajiv D. Banker, Srikant M. Datar, and Chris F. Kemerer,
    Management Science,
    Volume 37, Issue 1, pages 1-18, January, 1991.
  5. Experimental Designs: Testing a Debugging Oracle Assistant
    by Eugene H. Spafford and Chonchanok Viravan,
    Software Engineering Research Center,
    Department of Computer Sciences,
    Purdue University,
    SERC-TR-120-P
    December 18, 1992
  6. Social Integration as a Tool for Managing End User Computing and Decentralized Information Technology
    by Ralph David Westfall
    Fourth Annual Conference Proceedings, C. E. T. Rohm, Jr. (ed.),
    International Information Management Association, San Bernardino, CA,
    pp. 1-9, 1993
  7. Staffing Factors in Software Cost Estimation Models
    by Chris F. Kemerer and Michael W. Patrick
    Chapter 11,
    Productivity Handbook,
    University of Pittsburgh,
    New York: McGraw-Hill, 1993,
  8. Factors Affecting the Programming Performance of Computer Science Students
    by John B. Raley (master's thesis)
    Virginia PolyTechnic Institute and State University
    1996
  9. The 28:1 Grant/Sackman legend is misleading, or: How large is interpersonal variation really?
    Lutz Prechelt
    Fakultät für Informatik
    Universität Karlsruhe, Germany,
    Technical Report 1999-18
    December 20, 1999
  10. An empirical study of working speed differences between software engineers for various kinds of task
    Lutz Prechelt
    Fakultät für Informatik
    Universität Karlsruhe, Germany,
    submission to IEEE Transactions on Software Engineering
    February 16, 2000
  11. Pair Programming vs. Side-by-Side Programming
    by Jerzy R. Nawrocki, Michal Jasinski, Lukasz Olek, and Barbara Łange,
    Poznan University of Technology, Poland
    Springer,
    Lecture Notes in Computer Science,
    Volume 3792, pages 28-38, 2005.
  12. Software Process Improvement – EuroSPI 2005 Conference,
    edited by R. Messnarz, P. Abrahamsson, and I. Richardson
    EuroSPI, c/o ISCN LTD, Bray, Co. Wicklow, Ireland
    proceedings of European Software Process Improvement Conference,
    Budapest, Hungary,
    November 2005.
  13. Ein Experiment zur Ermittlung der Programmierproduktivität von Studenten
    by Matthias Wetzel,
    Universität Stuttgart, Germany,
    SEUH-10, 2007.
  14. Impact of Team Skills on Software Quality: A Comparative Study of Software Development Teams in India and United States
    Viji Vinod (dissertation),
    Dr. M. G. R. Educational and Research Institute,
    Chennai, India,
    February 2010.
  15. Estimation fulfillment in software development projects
    by Matthias Biggeleben (dissertation),
    Johann Wolfgang Goethe-University,
    June 15, 2011.
  16. Ontwikkelaars vergelijken op basis van broncode
    by Maarten Kieft (master's thesis)
    Universiteit van Amsterdam
    February 2012
  17. Teaching Artifacts
    by Titus Barik
    North Carolina State University
    2013.

FAQs

Most of the words which I have published are in the various FAQs (frequently asked questions) documents which I maintain:

In each case, my motivation was the same: reduce the amount of repetition I had to make in explaining the reasons for common problems and their respective solutions.

The ncurses and xterm FAQs are widely cited. Some of the more interesting ones:

In addition to citing, the xterm FAQ is included in the Debian xterm package.

Other mentions

Web searches and reading the bug-reporting systems finds me involved (and credited for my work). I will not try to duplicate that.

There are always potential biographical summaries. When Richard Stallman sent me mail in October 1999, advising me that I was “official” ncurses maintainer, he requested among other things that I write an entry for http://www.gnu.org/people/people.html. I did not (commenting to an associate at the time) that there was no point in doing so, because there was no check for content added there (aside from appropriateness). I do supply the content for the GNU page for ncurses.

The same comment would be true of most biographical summaries found in published works: the information is supplied by the author, and fact-checking seems to be perfunctory judging by the occasional scandals in that area.

That said, I have been told about my actual or proposed inclusion in these standard collections. I have not verified any of them. It seems that the publisher sends mail, saying that they are going to include you in some (specific) edition, that they want your biographical information. And, by the way, you can order a copy of the book (I recall prices around $100). Actually, I think that paying $100 to have my name in a book is a poor deal.

Herewith, the list (which I do not add to my resume):

There were 2-3 later requests for biographical data, probably while I was at the Software Productivity Consortium. Thinking back, it has been a while since I saw one of those—my visible activities starting with 1994 have been separate from employment, making me less interesting to those publishers.

Testimonials

Testimonials are less interesting than acknowledgements.

People do send me email making comments which could be used for this purpose (and I thank them). However, I do not publish these, having observed how testimonials are used (and abused).

For instance, in the mid-1990s I noticed testimonials added to the webpage for a well-known program. I recognized one of the names quoted there (someone who had made suggestions for some of the programs I develop). However, I recalled that this person was a regular contributor to that same program. I researched the names of the others providing testimonials, and found that half of the testimonials had been written by the developers themselves.

Enough said, perhaps.