Making Complicated Machines 

Computers offer a fascinating window into the play between the simple and the complex. The alphabet of computer language is as simple as they come, with two figures: 1 and 0, known as bits, which typically correspond to high and low voltage electronic pulses. From such a simple base, however, complex functionality can be achieved. On the other hand, seemingly simple behavior can require a substantially complex arrangement of ones and zeros. It also requires well-designed complex machinery to sculpt the flow of bits into something useful.

In Computer Organization and Design, David Patterson and John Hennessy describe in detail the design of a particular type of machine and its instruction set called MIPS (originally for Microprocessor without Interlocked Pipeline Stages). MIPS is one way to create the balance needed to make a good computer. The questions at hand in designing such a system include: what functionality need be built directly into the machine itself? how will instructions be represented? how will data be represented? how will the reduced set of operations be sufficient to accomplish a wide variety of more complicated operations? how will these operations be carried out quickly and efficiently?

The authors outline four design principles that guided the solutions to these problems in MIPS. The first of these, “simplicity favors regularity,” indicates that a reliably consistent design affords simpler solutions. For example, MIPS-32 uses a consistent ‘word size’ of 32 bits, meaning instructions and pieces of data are represented by a string of 32 ones and zeros. Having a regular word size allows for some simplicity in the hardware, for example: 32 wires, one for each bit, can be used to communicate both instructions and data - in fact, the same group of 32 wires can be used for either purpose and for any instruction or piece of data. The second principle is “smaller is faster.” Whatever the medium, the representation of bits has to travel through the computer. Shorter travel distances allow for faster computation, plain and simple. The third principle, “make the common case fast,” sometimes requires compromise. “Smaller is faster” asks for a small set of instructions and corresponding hardware, “make the common case fast” asks for instructions and hardware for as many frequently-used operations as possible. Hardware built to parse and quickly compute a larger instruction set take up more space, which can in turn slow down the overall function of the computer. These two principles must be balanced for maximum computing power and speed, which leads to the fourth guiding principle: “good design demands good compromises.”

These four principles all inform the design of MIPS. Thirty-two memory registers are kept close to the processor for temporary storage of 32-bit words currently in play. Access to these words is fast because of their proximity. Likewise, only six bits are required to indicate each, leaving room in 32-bit instructions for a wider variety of common instructions involving values in registers. The size of the architecture is kept small by reusing parts with basic functionality for multiple tasks. Compromises are made to reduce size while accommodating common cases: addition, subtraction, multiplication, and division are built into the instruction set and the hardware. To take a square root, the operation must be broken down into more basic parts.

In The Soul of a New Machine, Tracy Kidder follows Data General, a successful computer company, through the late 1970s as a team within the company worked feverishly to build a state-of-the-art microcomputer. This new computer, the Eagle, needed an architecture built from scratch with lofty restrictions and goals in mind. At the time, Data General’s bread and butter was a 16-bit microcomputer called the Eclipse. The Eagle would be a 32-bit machine roughly based on the Eclipse. It also set out to be backwards-compatible with the Eclipse: software written for the Eclipse needed to work on the Eagle.

There were also realities in place which added further restrictions to the design of the Eagle. Development of the Eagle was set on a very short timeline: one year. Why? The team working on the Eagle in Massachusetts was subject to competition with another Data General group in North Carolina, also working on a new 32-bit flagship microcomputer. The North Carolina group had a head start and was favored by the company. In fact, the Eagle team operated low key within the company, and included mostly junior engineers fresh out of school. Data General, meanwhile, was playing catchup with rival DEC, which had already brought a 32-bit machine, the VAX, to market.

The need for backwards-compatibility with a 16-bit instruction set, combined with the limitations on time and resources added to the compromises required to design and build the Eagle, and get it out the door.

The size of the instruction set was already a compromise. Doubling the word size would cause an increase in the size of the parts of the computer, working against the “smaller is faster” principle. The increased word size also vastly increased the number of instructions and data that could be represented with a single word, accommodating more common cases. Sixteen bits offer a vocabulary of about 66,000 words. Thirty-two bits represent 4 billion. In this case, the overwhelming vocabulary gain of the increased word size outweighed the speed hit of the size increase. The jump from 16 to 32 bits also offered another gain. According to Kidder, Eagle’s architect Steve Wallach reasoned that the increase led to “the enlargement of the Eclipse’s logical-address space from 65,000 to 4.3 billion storage compartments.” The number of spaces in memory that could be addressed increased 65,000-fold.

In building the Eagle, the second principle, “smaller is faster,” carried less weight. The goal was to fit the Eagle’s processor onto seven boards, where other companies were making machines using a single board. According to Kidder:

A multiple-board CPU performs simultaneously many operations that a single-chip CPU can do only sequentially… A time was probably coming when components would operate so quickly that the distance that signals had to travel would intimately affect the speed of most commercial computers. Then miniaturization and speed would become more nearly synonymous. But that day had not yet arrived.

Compromises between what operations the hardware and software would handle also took place. However, decisions about how to make these compromises were not always geared toward making the Eagle a fast and efficient computer, and more toward ensuring the Eagle would actually be a computer:

One Hardy Boy [working on the hardware], Josh Rosen, looks around and can hardly believe what he sees. For example, Microkids [working on the low-level software] and Hardy Boys are arguing. A Microkid wants the hardware to perform a certain function. A Hardy Boy tells him, “No way - I already did my design for microcode to do that.” They make a deal: “I’ll encode this for you, if you’ll do this other function in hardware.” “All right.”

What a way to design a computer! “There’s no grand design,” thinks Rosen. “People are just reaching out in the dark, touching hands.” Rosen is having some problems with his own piece of the design. He knows he can solve them, if he’s just given the time. But the managers keep saying, “There’s no time.” Okay. Sure. It’s a rush job. But this is ridiculous. No one seems to be in control; nothing’s ever explained. Foul up, however, and the managers come at you from all sides.

This way of working was even encouraged by the project’s manager, Tom West, who kept the following written on his white board: “Not Everything Worth Doing Is Worth Doing Well.” The limited time and resources available to the project compromised the overall quality of the design of the Eagle itself. There was, however, another human factor contributing to the inability to produce an ‘ideal’ design. West, a talented engineer himself, feeling the pressures of looming deadlines, decided at one point to try to examine flaws in the design to debug problems himself. After a few weekends of looking at the prototypes, West decided, “We’re way beyond what any one person can do. It’s too complex.” The complexity of the design and workings of the Eagle had become great enough that a complete understanding of all the details, decisions, and compromises involved in its engineering was unattainable.

Design, like engineering, is about problem solving. When setting out to design a computer architecture, several problems are at play. Machines need to be fast and small. They also need to be reliable and easy to fix or debug. Preferably, they adhere to some standards to ease programming by offering a consistent base for development. In the case of the MIPS architecture, one of the major design goals was simplicity. The design of the MIPS architecture, led by John Hennessy, began in 1981 at Stanford University, where the demands of the business world did not impose unreasonable restrictions on time and resources. Aspects of the design could therefore be thought out more carefully than the business-world could afford, lending the design a more complete overall grace and understandability. Data General’s Eagle team, however, had to sacrifice this idealism in favor of making a machine that worked and would be marketable. This was born out in West’s policy, “If you can do a quick-and-dirty job and it works, do it.” The MIPS architecture balanced simplicity and complexity in a wholly different way than the Eagle. The difference lay in the problems that needed solving.

Some Thoughts on Choice and Reason 

Last week I read Michael Bierut’s On (Design) Bullshit in Design Observer from a couple of years ago. He talks about the need to give reasons for design choices in order to sell your work to clients:

Before I could commit to a design decision, I needed to have an intellectual rationale worked out in my mind. I discovered in short order that most clients seemed grateful for the rationale as well. It put aside arguments about taste; it helped them make the leap of faith that any design decision requires; it made the design understandable to wider audiences.

In my far more limited experience working with design, this is true and apt. Even when ‘the client’ is yourself, rationalizing decisions makes you feel better about your own work in the ways that Beirut describes. Beirut himself admits that these rationales amount to bullshit, and at the end of his essay leaves off with an amusing anecdote:

I remember working years ago with a challenging client who kept rejecting brochure designs for a Francophile real estate development because they “weren’t French enough.” I had no idea what French graphic design was supposed to look like but came up with an approach using Empire, a typeface designed by Milwaukee-born Morris Fuller Benton in 1937, and showed it to my boss, Massimo Vignelli. “That will work,” he said, his eyes narrowing.

At the presentation, Massimo unveiled the new font choice with a flourish. “As you see,” he said, “in this new design, we’re using a typeface called Ahm-peere.”

I was about to correct him when I realized he was using the French pronunciation of Empire.

The client bought it.

In this example, it is clear that the reasons for choosing Empire did not include the fact that it is French, because it is not. However, this was the rationale given to the client, who had some predisposition to thinking that the design somehow needed to be French. The client had a desire that needed fulfilling, and the designers did so with bullshit. This bullshit rationale, however, made the choice of font perfect in the eyes of the client.

It may be hard to see this as a ‘bad’ thing overall, because Beirut ostensibly did not choose the font under those same false pretenses. However, this same process - desire or need followed by false fulfillment - can take place internally. In other words, when we are already looking for a particular reason to like a choice we have to make, we can easily be too quick to provide ourselves with a satisfactory bullshit reason why a certain choice fits what we need or want to accomplish.

In this way, having reasons that we are predisposed to sets us up to make some choices by default, without considering other options. The important question, when reviewing your own work or someone else’s, is not always “Why did you make this choice?” Sometimes it is “What choice did you make here?”

Michael Beirut recently announced the publication of his first book, Seventy-nine Short Essays on Design.

Teaching 

I still believe that teaching is my true passion. Maybe it’s because it can so easily incorporate all of my different talents. Maybe it’s because it allows me to persistently ask why. I still feel that the best—maybe the only—way to learn is by teaching. Teaching requires a truer, deeper understanding of material. Even at that, it still allows your students to open your eyes every now and then. Maybe I could teach people how to teach. This is why I’ve become so “artsy”—liberal arts schools teach you how to think. Other things start to feel rote—driven by competition. And that’s certainly not what I believe drives a good means of education. This is my key complaint against TAMS—it is far too competition-driven. I want to show the world that life is a journey, not a contest. I want the world to run on cooperation, not competition. I want to shed all the rhetoric and bullshit and help pry open every person’s eyes to reality—even if only slightly. I want to make a difference.