20. Where Do Great Designers Come From?
John Cocke (1925–2002), computer genius
IBM Watson Research Laboratory
Genius will live and thrive without training, but it does not the less reward the watering pot and pruning knife.
MARGARET FULLER [1820–1850], DIARY ENTRY
Every man who rises above the common level has received two educations: the first, from his teachers; the second, more personal and important, from himself.
EDWARD GIBBON [1789], MEMOIRS
OF MY LIFE AND WRITINGS
I have just argued that great designs come from great designers, not from great design processes. Although technical designs are now always the work of teams, we still identify the great designers around whom the teams formed: John Roebling (the steel-cable Brooklyn Bridge), George Goethals (the Panama Canal), R. J. Mitchell (the Spitfire), Seymour Cray (the CDC 6600, the Cray 1 supercomputers), Ken Thompson and Dennis Ritchie (UNIX).
A peculiar concern facing producers of high-technology designs is the inherent conflict between the solo design paradigm that has yielded great works in the arts, literature, and engineering, and the team design paradigm now demanded by the complexity of our artifacts and the tempo of our economies.
• How can we grow great designers?
• How can we develop design processes that support and enhance great designers instead of shackling them and homogenizing their work?
• How can we best support great designers with teams?
We Have to Teach Them to Design
Our formal education of designers is often dead wrong. Schön,1 paraphrased, says: “Technical Rationality holds that all professions should be taught as engineers still are taught: first the relevant basic and applied science, then the skills of application.”
Schön strongly disagrees with Technical Rationality on this point. He argues that all professional skills are mastered by critiqued practice. He argues that this is true of medicine, law, the ministry, architecture, art, music, social work, and indeed engineering. Medical education recognizes this, and from third year on, students spend more and more of their time in clinics, in grand rounds, and taking responsibility for patients. Architectural education has never lost sight of this truth, so studio dominates in all years.
On the other hand, in America most engineering designers spend most of their formal education in the classroom, or in the lab doing prescribed experiments, not doing designs to be critiqued. The same is even more true of software engineers.
Schön’s argument rings true to me. In such education we are misusing the most precious commodity in the education process: student time. Increasingly, engineering schools are reinserting critiqued design practice into the curriculum, in spite of the high faculty investment required.
It has been argued that engineers, hardware or software, have to know the basic science underlying their practice, and they have to know it first. The best modern engineering education refutes this and starts critiqued design in the freshman year, concurrently with science education. Only rarely do computer science curricula do that.
Similarly, strong engineering curricula often include “co-op” or “sandwich” programs, in which students intersperse on-the-job practice (and company training) between initial and final academic education. This practice is still far too rare in computer science curricula.
The weakness of much academic formal education is its reliance on lectures and readings, as opposed to critiqued practice. Effective education in design styles will have the pupil doing a well-constrained computer architecture in the style of Cray, a fugue in the style of Bach, or a building in the style of Wren. A knowledgeable and discerning mentor will then point out stylistic inconsistencies and critique the overall excellence of the design for its constrained objectives.
Such critique requires a certain confidence, even boldness, on the part of the mentor in engineering and computer science. Our emphasis on science has made us perhaps reluctant to engage in free-form subjective criticism, and inexperienced in offering it. Yet such is essential for teaching design.
Students can also mentor each other in such critiqued practice. The most effective way for a designer to learn other design styles is to undertake to teach them to other designers.
We Have to Recruit for Design Brilliance
All too often a manager recruiting new designers assesses them subconsciously on the criteria for the manager’s own job—“Could he do well the job I’m doing?” This favors the articulate, the leader, the person who will be effective in meetings. It tends to overlook the introvert, the slow-spoken, and especially the unconventional. But brilliant designers come in these packages, too! (I do not assert that brilliant designers are more likely to come in such packages. I don’t know.) We managers overlook these gifted ones to our great loss, theirs, and society’s.
How can we select better? First, by reminding ourselves what we seek. Second, by looking at portfolios of the design work itself, not just oral presentations about the work. Microsoft, for example, has candidates craft programs; this is not yet a universal practice among software engineering firms.
We Have to Grow Them Deliberately
Most substantial industrial and military organizations have elaborate and well-developed processes for growing people from worker to manager to executive to top executive. At each career stage, there is another education program for the new lieutenant, new major, new general. Promising talents are identified early and tracked. Mentors are assigned. Rotation of assignments gives a carefully planned variety of experience. The most promising are assigned to hitches as aides to the top professionals. The most promising young lawyers clerk for Supreme Court justices.
God trains many leaders this way. Moses, by a “fluke,” was trained to lead a nation by growing up as a prince in the court of a pharaoh. David, as King Saul’s harpist, observed how a kingdom was run and fair judgments were made. The apostle Paul was prepared to articulate and expound a totally new understanding of God’s ways by a superb education in the Old Testament at the feet of Gamaliel, the greatest rabbi of his day.2 He was then radically transformed by an encounter with the risen Jesus Christ and sent for a period to the desert, to think it all through afresh.3
I do not see most technical organizations giving thought to crafting a similar in-the-trenches approach to the development of nonmanagerial technical leaders, much less the great designers on whom the company will critically depend.
Make the Dual Ladder Real and Honorable
The first task for growing designers, as opposed to managers, is to craft a proper career path for them, one whose compensation and sociological status reflect their true value to the creative enterprise. This is commonly called the dual ladder. I have treated this elsewhere; here I only repeat that it is easy to give corresponding salaries to corresponding rungs (and market forces tend to make that happen), but it requires strong proactive measures to give them equal prestige: equal offices, equal staff support, reverse-biased raises when duties change.4
Why does the dual ladder need special attention? Perhaps because managers, being human, are inherently inclined to consider their own tasks more difficult and important than design and need to deliberately assess what makes creativity and innovation happen.
Plan Formal Educational Experiences
Budding designers, like budding managers, need a combination of continuing formal education interspersed with actual hands-on practice that is guided and critiqued by a master designer.
Why formal education? Today’s world continually changes. In the high-technology disciplines, the rapid obsolescing of a technical education is self-evident, and almost frightening. Since I got into the computer field in 1952, my professional intellectual life has been a big sea bath in a heavy surf. As soon as one stumbles up after one breaker, here comes the next! Thoroughly invigorating, thoroughly enjoyable, and ever varying. So the first reason for formal education is continual retooling.
I have personally found formal short courses an effective and economical method for retooling—I have averaged one per year. Why? Can’t one keep up by journal-reading and conference-going? Indeed one can! But I am a believer in formal education—a good teacher who carefully prepares a balanced overview of a subject can improve my learning efficiency by a factor of two or more and can quickly give a balance and perspective that would require studying literally dozens of journals. As a teacher who undertakes to deliver that kind of learning efficiency to my customers, I try also to buy it for myself.
A second reason is deepening and broadening. This is most effectively done by studying both good and bad designs of predecessors and contemporaries. For this purpose the principal advantage offered by formal education is detachment—the professional teacher is more apt to study competing design concepts and styles. As the culture inside any design shop emphasizes its own traditions and viewpoints, so does company-sponsored formal education. This is the best reason for budding designers and their mentors to seek formal education outside.
My most productive single act as an IBM manager had nothing to do with product development. It was sending a promising engineer to go as a full-time IBM employee in mid-career to the University of Michigan to get a PhD. This action, which at the time seemed to a busy computer architecture manager to be just a quite incidental personnel activity, had a payoff for IBM beyond my wildest dreams. Ted Codd’s PhD prepared him for a research career; his research led him to invent the relational database concept and to receive a Turing Award.5 Relational databases have been the principal application of IBM’s most profitable computer line for over 25 years.
Plan a Varied Set of Work Experiences
As the best organizations now do for budding managers, so we need to do for budding designers. The critical word is plan; the course of the young career should itself be designed—for variety, for depth of involvement, for spiraling challenge and responsibility.
Often the most fruitful of early assignments have young designers serving in the organizations of the users of the objects they design. My own short-term jobs in a commercial data-processing shop building a 40-state payroll program, in a scientific computing shop calculating rocket trajectories, in a cryptanalytic shop, in a telephone switching laboratory identifying dialers on four-party lines, and in an engineering-physics lab measuring ground vibrations in milli-inches have been priceless in helping me understand computer users’ requirements viscerally. As described in an earlier chapter, my two-week stint as an apprentice computer operator, hanging tapes in a glass house, also gave me a blast of reality when I designed an operator console. Dewey was right that we learn by doing; the effective growth curriculum of the designer must include a variety of experiences.
Plan Sabbaticals Outside the Organization
The mid-career designer can be refreshed and broadened by a sabbatical outside the organization—perhaps on loan to a customer; perhaps teaching at a university; perhaps on assignment with a federal agency. Preventing stagnation of creative people is a great investment.
We Have to Manage Them Imaginatively
The John Cocke–Ralph Gomory story
John Cocke was probably the most brilliant and surely the most creative person I have ever known. We both joined IBM in its Stretch supercomputer project in July 1956, with fresh PhDs, and we shared a bullpen then and later a two-person office. That arrangement was fine because John, single, worked at night, and I worked in the daytime. John was passionate about computers, all aspects. I suspect he spent more hours every day thinking about computers than he did thinking about everything else combined. He understood in depth not only computers, but all the supporting science and technology.6 And he was a rare combination—both deeply thoughtful and outgoing; like the Ancient Mariner, “he stoppeth one in three” to explain his latest ideas. It was impossible not to love John—genial, generous to an extreme degree, and always excited. Harwood Kolsky’s memoir vividly captures many aspects of John’s personality, style, and presence.7
Cocke attracted great collaborators, who helped capture and helped implement his incredibly numerous ideas. Three of these ideas, each worthy of the Turing Award, were instruction pipelining with Kolsky,8 global compiler optimization with Fran Allen and Jack Schwartz,9 and the reduced-instruction-set computer architecture with George Radin.10
Now how could an idiosyncratic genius like John Cocke, who couldn’t manage a group, rarely published anything, and mostly just thought and talked to bright people, make so many major contributions? There are two geniuses in this story, and the other is Ralph Gomory, IBM’s Director of Research and Senior Vice President for Science and Technology. Like Cocke, Gomory received the National Medal of Science for his own contributions.
Gomory created an organization, atmosphere, and organizational management style that aimed to enable each person in IBM Research to contribute in the way that best suited his particular bundle of talents. Ralph says, “I didn’t treat John any differently from anyone else.” But his statement misses the point: he treated each of his great minds differently—according to their nature and needs. He also says, quietly proud, that “John was the highest-paid person in IBM Research, because he was the highest contributor.”11
We Have to Protect Them Fiercely
Protect Them from Distraction
Once we have great designers, we want them to design. Design productivity requires flow, an uninterrupted mental state of high creativity and concentration. We designers have all experienced and covet its delights. DeMarco and Lister have an excellent discussion of flow, its importance, and how to achieve it in Peopleware.12
The modern organization has many hindrances and diversions to prevent flow:
• Meetings
• Phone calls
• Emails
• Rules and constraints
• Staff bureaucracies and “service” groups, who make rules to simplify their own jobs
• Customers
• Professional visitors and journalists
Many creative organizations have adopted procedures such as “quiet mornings” to enhance flow. When IBM was trying to catch up with Apple after the introduction of the first personal computers, CEO John Opel established a closed laboratory in Boca Raton to develop IBM’s entry. Other IBM employees, including even corporate staffers with defined relevant responsibilities, simply were not permitted to go in.
Similarly, I closed the System/360 project to non-project visitors, both IBMers and customers, from January to April 1964. We had too much work that needed flow.13
I interviewed Jeffrey Jupp, Technical Director of Airbus UK, on the design and manufacture of wings in Britain for Airbus planes whose fuselages were designed and manufactured in France. Late in our fascinating conversation I asked if I could speak with his chief designer. “No” was the simple answer. I understood and respected it.
Protect Them from Managers
A mediocre or insecure manager can smother any designer’s creativity. Often a mediocre manager fails to recognize the jewels on his team. Sometimes he doesn’t realize the crucial nature of design to his team’s success. Sometimes he doesn’t understand his own role of enabling design magic.
Sometimes the manager resents, or cannot admit, that the “subordinate” designer is in fact the better designer. Sometimes the manager is offended if the exceptional designer is paid more than he. The result is lack of encouragement, lack of facilitation, petty put-downs.
The task of higher management is then quite clear: they must actively change the first-line manager, ideally by raising his vision of his own talents and special role, and by training him in team encouragement and leadership.
Protect Them from Managing
I have seen potentially great designers sidetracked from design into management. They never reached their potential. The culture of our organizations, alas, encourages or even forces this. Intention, nay, determination, is required to swim against that culture.
Seymour Cray, the greatest supercomputer designer ever, furnished an inspiring example. Cray was a designer of first-generation vacuum-tube computers in the hotbed at St. Paul, Minnesota, first at Engineering Research Associates, and then at Control Data Corporation. To design the CDC 6600, he moved his team of “thirty-five people including the janitor” away into seclusion and disentangled himself from all other CDC responsibilities.14
When the dramatic success of the 6600 involved him again in CDC management, he arranged a departure, with CDC’s blessing, to found Cray Computer Corporation, working on a secluded prairie site. He personally oversaw all aspects of the Cray 1, from circuits to refrigeration to the Fortran compiler.
Then, as Cray Computer blossomed with success and involved him again in management, he pulled a team away to Colorado to form Cray Research Corporation. Only a drunk driver ended the determined pattern.15
Growing Yourself as a Designer
Suppose you are a technical designer and want to improve. Is there any counsel from outside your own discipline that can help? I think so. You must start by planning your own growth program.16 You alone are responsible for it.
Constantly Sketch Designs
Designers learn to design by designing. Some of the sketches need to be fully detailed, for the devil is indeed in the details, and many a grand scheme has foundered on a little submerged rock. Leonardo’s Notebooks are a rich example of how this is best practiced. The aspiring young software designer might well keep a notebook of patterns he encounters and invents in his own constructions.
Seek Knowledgeable Criticism of Your Designs
Donald Schön, in his superb book Educating the Reflective Practitioner, argues extensively that critiqued practice is in fact the only successful method of teaching practice. He cites discipline after discipline—law, medicine, architecture, masonry, the medieval craft guilds—as having evolved (probably independently) to this method of teaching.17 The modern PhD dissertation is exactly such a method of teaching the practice of research.
Study Exemplars and Precedents
In this practice, you emulate many great designers. Robert Adam studied Christopher Wren. Wren studied Palladio. Palladio begged support from his father to go to Rome and measure and draw the remnants of great Roman buildings. The Romans studied and fused the architectural styles of the Etruscans and the Greeks. Each great designer mastered the rich legacy of his predecessors and then added his own new concepts.
The proper study of exemplars demands humility of approach. Those precedents whose reputations have survived centuries of criticism have some deep excellence. In newer fields, the available span may be only decades. But however deep the pool of precedents, the task of the student is to find and master the excellence that has gone before, even if his muse or his new circumstance then drives him in a totally different direction.
The computer architect needs to study the whole variety of commercially produced machines. Someone thought they were good enough to merit the investment of real money. (The much more numerous published-only architectures have passed no such stringent test and hence merit far less study.)
In approaching a precedent design, it is crucial to assume competence—the right question is
“What led such a smart designer to do that?”
rather than
“Why did he do such a fool thing as that?”
Usually, the answer lurks in the designer’s objectives and constraints; discovering it usually brings new insights. Whereas in marital disagreements, the wise and usually truthful answer to the “Why did you . . . ?” or “Why didn’t you . . . ?” question is “Lack of sense,” that is rarely true when one probes a design decision.
When possible, listen to contemporary designers discussing their work. When possible, read what designers have written about their works.
Gerry Blaauw and I have found it very instructive to cast our own studies of others’ computer architectures into a common format—common structure, standard sketch scale, common prose description elements, common formal description language—with a short prose critique of the highlights and peculiarities of each.18
A Self-Education Project—Floor Plan for a 1,000-Square-Foot House
From a beginning design course at the North Carolina State University School of Design comes a useful self-education exercise for designers, no matter what their design disciplines.
The Program
Design the plan of a 1,000-square-foot home for a family with two parents and two children, a son aged three and a daughter aged six. The site is in northern Virginia, suburban, 50 feet on the street, 70 feet deep, somewhat wooded, and facing south.
Journal
Keep a dated journal of your design questions, decisions, and reasons. Here are some questions to address:
• Fabricate a more detailed architectural program, using your imagination. Put it in your journal.
• What constraints did you deduce from the given program?
• What was the budgeted commodity? How did you manage it?
• What desiderata did you follow, explicitly or implicitly?
• How did you decide which of two design alternatives was better?
• Did you use a CAD tool? If so, assess it versus sketching, for the different phases of your task.
• How did you proceed? Analyze your journal and sketch your design trajectory.
• Assessment: What are the good points in your design? The weaknesses?
Notes and References
1. Schön [1986], Educating the Reflective Practitioner.
2. Acts 22:3; Wikipedia on “Gamaliel” (http://en.wikipedia.org/wiki/Gamaliel), accessed on April 25, 2008.
3. Galatians 1:17–18; Acts 22:3. However, in contrast with all of these, Jesus was blocked from getting training by the Old Testament experts and had to rely on memorizing the Scriptures and coming to a totally new understanding of them by meditating on them in the carpenter shop for many years (Luke 2:41–52).
4. Brooks [1997], The Mythical Man-Month, 118–120, 242.
5. Edgar Frank Codd, if you want to seek his work.
6. Even in his last illness, though chair-bound, Cocke regaled me with some new science and his latest ideas for how it could be applied to computers.
7. http://www.cs.clemson.edu/~mark/kolsky_cocke.html, accessed on November 26, 2008.
8. Cocke and Kolsky [1959], “The Virtual Memory in the STRETCH Computer.” This is really about instruction pipelining, not virtual memory as we know it today.
9. Cocke and Schwartz [1970], Programming Languages and Their Compilers; Allen and Cocke [1971], “A catalog of optimizing transformations.”
10. The Reduced Instruction Set Computer (RISC) concept is often misunderstood. The basic idea is not a reduced set of instructions, but a set of reduced instructions, that is, more primitive. In extreme form, there are no subsequenced instructions, not even a Shift N Bits or a Multiply. This enables the accumulator-adder-accumulator loop to be minimized, and with instruction cache and an optimizing compiler, everything goes faster. I know of no one besides John whose mastery of both computer design and compiler optimization could have so wedded those concepts. George Radin was an important collaborator, but the original papers, Radin [1982], “The 801 minicomputer,” and Radin [1983], “The IBM 801 minicomputer,” should have borne Cocke’s name as lead author, although I suspect he didn’t write a word.
11. Ralph Gomory personal communication [November 2008].
12. DeMarco [1987], Peopleware.
13. Samples of the letters of February 4, 1964, to the head of the Marketing Division, and to my boss and the laboratory manager are on the book’s Web site.
14. Murray [1971], The Supermen.
15. http://americanhistory.si.edu/collections/comphist/cray.htm, accessed on August 12, 2009.
16. The best advice I’ve seen for planning an academic career is given in Gilbert Highet’s Art of Teaching [1950], 21:
When a young German scholar was beginning his career, he used to choose three or four large fields in which he felt a real interest, on which there was a good deal of work to be done, and which—an important point—were all linked with one another, and which—most important of all—he felt to converge on the very center of his subject. He would contrive as far as possible to make these the subjects of his first classes and seminars. He would write groups of lectures on them, and nurse and nourish each group until it grew into a book. If he were energetic enough and percipient enough, he would thus become the author of three or four books, each of which would recommend and illuminate the others. He would then continue . . . enlarging [each field] strategically from year to year until he had built up a really authoritative knowledge of the whole subject. ... Scholars who planned their learning and their teaching in that way usually found ... that they had enough interests and nearly enough knowledge to fill three careers.
17. Schön [1986], Educating the Reflective Practitioner.
18. Blaauw and Brooks [1997], Computer Architecture, Chapters 9–16, “A computer zoo.” The standard format is described in Chapter 9.