Lorinda Cherry looks for "neat new things [to] make the computer do." She joined the UNIX project after working abroad to do work that interested her. She had received a BA from Stevens in Computer Science, but this degree did not include the theoretical basis or practical compiler know-how that Cherry had acquired in the work place. Cherry found "programming somebody else's ideas" boring, so she jumped at the chance to work under the less structured management of the UNIX project.
This environment demanded creativity and self-motivation. There was "no charging" for computer time, so people could push the limits, do "things that would take forever" in the background. "You invent your own projects", and take responsibility for them. "Programs floated from person to person because somebody would add a feature to Sort, and they owned Sort." They were the technical support for that program until somebody else picked it up. People would ask their colleagues for advice routinely. Cherry, for example, remembers, "I worked mostly in my office and visited the sixth floor with questions." One of Cherry's largest projects, Writer's Workbench, grew out of a part of speech program she was writing so that a co-worker could make computer-generated voices use the proper inflection and intonation.
To the end of helping co-workers produce better products, many projects were passed on to specialists who improved a certain aspect of a program. Bob Ross, for example, broke programs. He would "break things intentionally" to root out all the bugs in a program. Although he did not build these packages himself, Bob made the UNIX tools "very, very robust". This hardiness, moreover, allowed the tools to be used more easily by UNIX workers and by the public that would later accept the operating system.
The lack of hardware protection in the UNIX programming environment also facilitated communication. Anytime someone wanted to test a program, there was a danger of crashing the system. This danger required programmers to notify each other of any program trial. The programmers communicated through the "write" command, notifying each other of tests and later asking each other questions by means of the machine.
UNIX created a mindset in its programmers. Its "elegance, professionalism [and] ... textual flavor" stem from its theoretical foundations. According to Cherry, "it's highly disciplined in what's allowed to hang around and what isn t." The "divide and conquer" attitude made "more sense" to the UNIX programmers as they broke "things into small pieces." Cherry espouses the doctrine of "real meaning in UNIX, ... a way of doing things" with pipes and small efficient programs. The DOS concept of idioms offends Cherry, because it breaks from the logic and consistency of UNIX. To keep these small programs pure, the group had several de facto mechanisms that prevented "featurism". The idea of owning whatever you modified created "hesitancy, 'cause if you touched it, you owned it." Anything that was "not really necessary" was left out. This idea of ownership continues to this day as Cherry recalls that she was the "grandmother" of Workbench. The theory of UNIX spoke out against the "big monolithic things" being created elsewhere. Practically, unused programs would not make it into more complete versions of UNIX because "everything went to C." If a particular program was not deemed worthy it never made the transition from assembler.
The Writer's Workbench exemplifies the collaborative nature of the UNIX group. Using the existing textual analysis tools of Mosteller, several programmers began to play with text. Cherry designed a compression program based on trigram statistics. The program finds repeated strings of three characters and replaces them with a byte that references a dictionary of the replacements above. She helped Brent Aker with his work on the Votrex machine, a peripheral that spoke for the computer. The votrex did not intonate or emphasize properly. Cherry worked on a part of speech program that would allow the computer to pronounce words properly. The computer needed "part of speech ... for syllabic stress." Cherry describes how this program was built on to produce different results: There are various things you would count and look at using parts of speech to decide whether you ve got a compound or compound sentencing sentences types, so the part of speech program turned into the style program. "A layer on top of style and diction" filled the program with a wider range of capabilities.
The group maintained interest in this project because it was so useful for their work. They could "look at [computer] documentation and decide whether it was reasonable from a human factors standpoint." The work of "maintaining programs is maintaining text." The group intended to use this package themselves before they had even contemplated selling outside. After beta testing the software with Colorado State, they improved the workbench further. This program succeeded for three main reasons its reliability, structure, and the understanding of the programmers. The competing IBM product, Apistle, was based on a parser, making it slow and incapable of coping with incorrect student grammar. The "press-on-regardless" attitude of workbench leads to accuracy across the entire paper. The most important factor, however, was the programmers understanding of the writing process itself. They knew to present readability scales as estimates. They knew that the ultimate lesson was to teach students that writing is a series of choices, not a matter of pretty formatting.