Code Read 6 - Mitch Kapor's Design Manifesto

This installment of Code Reads takes a huge leap from the world of academia and the historic foundations of our discipline to something more recent: Mitch Kapor's Software Design Manifesto. In this passionate essay, Mitch Kapor extols the virtues of designing software with the user experience in mind, and advocates developing a profession of software design.

Today the phrase "software design" (like "architecture") has come to have so many definitions that Humpty Dumpty would grinning from ear to ear. So before we can comment on what Mitch Kapor had to say, we need to pay some attention to what he actually did say, and not what we read with our modern vocabulary.

First of all, he says "Software design is not the same as user interface design." However, he does go on to say that user interface design is an important part of software design. In his effort to wrench software design away from the pure engineers he repeatedly comes back to the importance of the user interface, and his prime motivation is a better "user experience", so it is easy to forget that he his talking about something larger that the UI.

He fervently opposes taking a purely engineering view of a program. "One of the main reasons most computer software is so abysmal is that it’s not designed at all, but merely engineered. Another reason is that implementors often place more emphasis on a program’s internal construction than on its external design..."

When he talks about software design, he is talking about the "metaphor" of the software. When describing his experience with good design, he says "It is the metaphor of the spreadsheet itself, its tableau of rows and columns with their precisely interrelated labels, numbers, and formulas ... for which [Dan Bricklin] will be remembered".

A modern example of a successful metaphor is the GUI windowing system that almost all of us love and know. It was not any individual UI that gave this approach its staying power - it was the simplicity and utility of the metaphor.

Unfortunately, it is an almost universal experience that finding such good metaphors is hard work. Finding non-programmers who have the skills required to do this is hard: "Many people who think of themselves as working on the design of software simply lack the technical grounding to be an effective participant in the overall process. Naturally, programmers quickly lose respect for people who fail to understand fundamental technical issues. The answer to this is not to exclude designers from the process, but to make sure that they have a sound mastery of technical fundamentals, so that genuine communication with programmers is possible." I have had quite a few arguments about software design with people who lacked even an accurate technical vocabulary, let alone a solid grounding.

However, the converse is also often true - many good programmers lack the leadership and aesthetic skills to make good designers: they often veer towards the stereotypically dictatorial auteur, or allow the engineering of the software to usurp the design.

People who try to play this role must have a very broad background, and depth of insight in a variety of fields, as well as strong leadership skills. Mitch Kapor suggests, "technology courses for the student designer should deal with the principles and methods of computer program construction. Topics would include computer systems architecture, microprocessor architectures, operating systems, network communications, data structures and algorithms, databases, distributed computing, programming environments, and object-oriented development methodologies." To which I would add "graphic design, industrial design, ergonomics, the study of perception, and psychology". Then I would also add some management training, and small-group dynamics, because good designers must also be good leaders - able to convince people of their point of view, and inspire collective effort.

We also clearly need some technical development in the field. "In both architecture and software design it is necessary to provide the professional practitioner with a way to model the final result with far less effort than is required to build the final product. In each case specialized tools and techniques are used. In software design, unfortunately, design tools aren’t sufficiently developed to be maximally useful." In fact, I would say they are only just beginning to be developed to be minimally useful - there is nothing very good right now for modeling the metaphor, or design of a program, without actually building the program.

Despite these obstacles, I am a firm believer in the ability of good design (especially a good metaphor) to make the difference between a Chrysler Building or a Robert Taylor Homes. This is, in fact, what I am hoping to learn about as I continue my education, and I will share what I find here on this blog.