Few software products are loosed upon the unsuspecting world with as little thought as the editorial product described in the following vignette. This story is not so much a cautionary tale-you don't need to be cautioned against doing something you'd never be fool enough to do-as it is a moron joke to set up this month's theme.
Since the time at which this story took place, editors have been changed to protect the innocent reader.
Back in October 1984, the then-editor-in-chief of this magazine introduced a column in DDJ called "The Software Designer." By "introduced," what I really mean is that this knucklehead announced in print that there would be such a column, without first lining up a regular columnist to write it. The lack of an author turned out to be a bit of a problem, especially for the aforementioned knucklehead-in-chief, who had to write most of the columns himself. The frequency, length, and content of the column were all, predictably, unpredictable. And yet, against all odds, the column seemed to strike a chord with readers.
The right idea can sometime triumph over a poor design.
A decade later, "Software Designer" is a real job title in some organizations, and there are schools offering multicourse programs in software design, including a Master's Degree program at the Royal College of Art, Stanford's Master's-level program in Human-Computer Interaction Design, and MIT's Program in Media Arts and Sciences. A professional organization, the Association for Software Design, has been formed. And while books on software design aren't as common as books on Java programming, there are several, many of the best of which have been discussed in this column. (Tog on Interface and Tog on Software Design, by Bruce Tognazzini; Computers as Theater, by Brenda Laurel; The Essentials of User Interface Design, by Alan Cooper; Things that Make Us Smart, by Don Norman.)
Of course there were books on software design back in 1984, but they rarely used that term (Paul Heckel's excellent The Elements of Friendly Software Design, Warner Books, 1982-84, ISBN 0-446-38040-7, is the standout exception), and they generally didn't treat software design as a separate discipline. If the poorly designed "The Software Designer" nudged people's thinking just a little in that direction, maybe DDJ deserves a tiny bit of credit for the way things are moving.
Less ambiguous credit is due to DDJ's 15th anniversary issue in January 1991. That was the issue that focused explicitly on software design, with several software-design articles and a bold manifesto by Mitch Kapor urging that we all get serious about software design. "Credit," that is, if you think that software design ought to be a separate discipline, which is the direction that issue was pushing things, especially through the Kapor piece. "Blame" otherwise. The point is, after all, debatable. Should software design be the job of a specialist, or should the implementor be the designer? This month, I discuss a book that presents the views of some twenty people on software design, and then I look at the legacy of one uncompromising developer who, probably more than anyone else, upholds the vision of the implementor/designer.
The book is Bringing Design to Software by Terry Winograd (ACM Press, 1996, ISBN 0-201-85491-0). Its purpose, according to ACM Press marketing, is "to illuminate and stimulate the discipline of Software Design." In structure, the book is a collection of essays by individuals with some stake in software design, introduced by Winograd and alternating with "profiles" by Winograd and others; these profiles turn out to be descriptions of products or projects that exemplify in some way the points made in each of the articles. Without this structure and Winograd's ordering of the contributions, these essays would read like a collection of papers presented at a conference-which is more or less what they are-rather than as a coherent exploration of a topic, which is how they do, in fact, read.
This is impressive, given that the book has contributions from a lot of "names," and the usual result of pulling together essays from a conference with a lot of big names is incommensurate perspectives, redundant coverage, pursuing of tangents, and self promotion. Granted that Mitch Kapor, David Liddle, Paul Saffo, Peter Denning, John Seely Brown, Michael Schrage, and Don Norman all have something interesting to say about software design, I wouldn't expect a book that includes all of them to be anything but a loose bag of essays. Although Winograd cautions that the reader will have to share some of the burden of pulling the contributions together into one coherent whole, it is to Winograd's credit that this is indeed possible, and that the book actually reaches conclusions by chapter 14 that it couldn't have reached in chapter 1.
The one reprint in the book, and the lead article, is Mitch Kapor's "Software Design Manifesto." This is the piece that appeared in the aforementioned January 1991 issue of DDJ, and it sets the right tone, speaking of poorly designed software as "the secret shame of the industry." Kapor argues for recognizing the separate and critical role of design, draws a parallel between building software and building buildings, and says that we have construction workers designing software when what we need are software architects. And he clearly states that we need formal training and recognition of software designers as members of a separate profession, equal to computer scientists and engineers.
The other contributions to the book take various forms. The Liddle piece is an interview. Although it covers what may be familiar material for some DDJ readers-the design of the landmark Star computer at Xerox, which soon put the gleam of Macintosh in Steve Jobs's eyes-the emphasis here is less on the Star and its influence on user-interface design than on the process of design engaged in at Xerox at the time. It deals with a question that is definitely worth asking: What were the conditions, goals, forces that permitted the development of such a radical break with current thinking about what constituted a personal computer?
If the Star experience had been an unqualified success, the book could be a lot shorter: It could describe the Xerox corporate culture, design goals, experience of the designers, team structure, and the like, and then say, "Here is the secret of successful software design: Go thou and do likewise." Well, the Star was not an unqualified success.
So when Liddle says, "Before we designed the Star, I commissioned a study that produced a document on methodology for the design of the user interface," we are free to consider this as a factor contributing to a breakthrough design, or as one reason the Star bombed in the market.
Perhaps the chief insight from the Liddle piece is his emphasis on the importance of the user's conceptual model and his distinguishing it from a metaphor. The user's conceptual model is not a metaphor, but what Ted Nelson calls a "virtuality." It doesn't have to represent some real-life thing; it becomes its own reality. Gillian Crampton Smith and Philip Tabor push the idea further: the Platonic assumption that there is something behind the interface is not true, in the user's experience: "As far as the user is concerned, WYGIWYS: What you get is what you see. The interface is the product."
If, to the user, the interface is the product, part of the design process needs to be deciding what the product is. David Kelly is explicit about this: He says that designers must "understand, observe, and visualize," and that visualization "is the act of deciding what it is." Is it a tape recorder, or is it a device for recording live opera, or is it a toy for playing tapes of tunes at the beach?
Kelly considers engineering to be mere implementation and emphasizes that design comes first, is a creative process, and requires a creative leap that is uncomfortable to the engineering mind. Donald Schon and others in this book tell a more complicated story: that development is a spiral process of design, feedback, and design tweaking, some of the feedback coming from users, some from engineering, and some, probably, from marketing. I say "feedback," but Schon prefers the phrase "backtalk cycle,"
"... steering slightly to the left when you should be moving to the right." They were being told, "This product is not what you think it is." Consumers were projecting onto the product meanings different from the intentions of the product designers.
This from Schon's enlightening discussion of design work on a product far from computer software, but wildly successful-Scotch Tape. Note again the emphasis on what the product is, but in this case coming from its users.
There is No Word in American English for the Opposite of Ownership
The latter part of the book moves toward an analysis of what sort of culture or organizational structure promotes effective design. Michael Schrage has some kind things to say about the prototyping culture at Apple. Don Norman, with more experience with the Apple culture, paints a different picture. Norman's piece is pretty funny, although there really aren't any good jokes in it. The humor comes from the intense wrangling and agonizing compromises that it recounts over something as simple as the location of the power switch.
Well, I think it's funny.
Schrage likes collaboration, thinks that prototypes are critical, and argues that the prototype must be community property, not the pet of one individual or group. In particular, executives have got to be clued in so they can understand that a prototype is a prototype and not a failed attempt at a finished product, or, worse, an actual finished product. ("Looks great. Ship it!")
Reading between the lines of Norman's war story, you get the idea that he wouldn't have minded too much in this case if there had been a little less collaboration and a little more doing what he wanted. Winograd's ultimate take on this is that "an organization can do much to support the process and ensure success" or it can "impede the design process, stifle creativity, and damn a project to software hell...." In other words, the book falls a little short of identifying what kinds and policies of organizations promote effective design. Ah well, if the book had all the answers, why would we need academic programs in software design?
Which we certainly do. Bad software design, as Sarah Kuhn points out, can have really bad consequences in the workplace: unnecessary job displacement, reduction of skills, loss of work autonomy and control. Even the placement of that Macintosh power switch can have life-and-death consequences, if it leads people to think that all power has been removed from the machine when it hasn't. Software design matters.
One reader writes to suggest that, since I've recently covered Forth-related languages in this column, I not overlook PostScript. Fair enough, but while I have written about Forth-related languages, I haven't done justice to Forth itself, and have said nothing about its remarkable creator, Chuck Moore. That first, then.
Forth, it needs to be said at the outset, is a great success. True, you probably don't use it, and very little commercial shrink-wrapped software or in-house software or shareware is written in Forth, and there aren't a lot of schools teaching Forth, and there aren't many books coming out on Forth, and you don't see much (any?) Forth code in magazines like this. Forth was created by Charles H. "Chuck" Moore. It's really Chuck's language, as few languages are one author's. That fact is, without question, the secret of its success, and, probably, the cause of its obscurity.
Forth is a success, first, because it met its design goals. Chuck has always thought of himself as an application programmer, and he wrote Forth to let him produce better applications faster, to "decrease the effort required and increase the quality produced." When the designer is the customer there may be some bias in the evaluation of the product, but Chuck has always seemed satisfied with Forth. Okay, not satisfied, exactly, since he rewrote it many times. Happy, though.
Forth has also succeeded in the embedded-systems world. The Open Boot programmable monitor on all SPARC workstations is written in Forth. And Chuck has spent years designing Forth chips of one sort or another for custom applications.
What made the development of Forth different from that of any other language was the total control the designer had over the language, and over the target machine through the language. Forth was designed in part in reaction against increasing software specialization and what Chuck saw a Tower of Babel of languages, all serving to insulate the application programmer from the machine. In Forth, Chuck created a language to replace the whole tower: assembler, operating system, compiler, the works. Forth slashed through this stack of tools and let the programmer work directly with the machine while doing high-level application programming.
"The programmer" in the early days (the 1970s) meant Chuck. He was his own market at first, and this gave him the freedom to radically redefine elements of the language on a daily basis. He did so according to his practical needs in developing applications, and also according to a philosophy. It was pretty much a one-principle philosophy: Keep It Simple!
He followed this principle to a degree that few could, or would, consider. The principle led to a corollary that seems heretical: Don't create a library of standard subroutines; let programmers write their own. Another corollary: Don't add features that might be useful. "The things you might want to do are infinite.... If you need an extension later you can code it later."
Forth became a model of conceptual economy.
It became one of the most efficient development tools ever created. And it was designed, like the Apple I motherboard, by a designer/engineer who solicited no feedback from users and designed exactly the product that he himself wanted.
I wonder if that approach is being taught in any of the Software Design curricula.
Nothing keeps an enterprise alive and healthy like a passionate and knowledgeable and actively involved champion. Chuck Moore has always been that. Here he is in a letter to the Forth publication Forth Dimensions (Vol. 3 No. 1, 1983), defending a particular practice of Forth Inc., that of storing names as three characters plus a character count:
DEA- EDI---
I AM AFR--- THA- THE LET--- IN THE LAS- ISS-- ABO-- FOR-- INC- USI-- ONL- THR-- LET--- NAM- FIE--- HAS HAD THE OPP----- EFF--- FRO- WHA- THE WRI---WAN---
HIS LET--- ( LIK- THI- ONE ) SHO-- THA- SAV--- ONL- THR-- LET---- AND COU-- IS JUS- ABO-- OPT---- IN TER-- OF A TRA-- OFF BET---- SAV--- MEM--- AND KEE---- LEG-------
WE STI-- DON-- SEE THE NEE- FOR 31 CHA------ NAM-- IN THE GEN---- CAS-
YOU-- TRU--
CHU-- MOO--
FOR-- INC-
That issue of Forth Dimensions was actually on the aforementioned knucklehead's desk when he was planning that software-design column. It's a wonder it didn't come out as "The Sof----- Des-----."
Til- nex- tim-
Mik- Swa---