This is the sixth edition of Code Reads, an aspiring-to-weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s thefull Code Reads archive.
Mitch Kapor first presented his Software Design Manifesto at PC Forum in 1990. It got published in Dr. Dobbs’ Journal in 1991, and later appeared as the first chapter of Terry Winograd’s book Bringing Design to Software (much of the book is available in online form now). At a point roughly midway between the start of the personal-computing revolution in the mid-’70s and the present, Kapor threw down a gauntlet: Computers were too hard to work with. “Everyone I know (including me) feels the urge to throw that infuriating machine through the window at least once a week,” Kapor wrote.
The PC revolution’s promises of “personal empowerment” remained unfulfilled because the software that drove the miraculous new machines was simply not well-enough shaped. The people who made it weren’t thinking clearly enough about how their products would be used. Somebody had to do that work; Kapor argued that programmers probably weren’t the best people to take it on, and proposed the creation of a new discipline of “Software Designer” to wear this mantle.
This person’s role incorporated some of the work often associated with the “software architect” on the one hand and the “interaction designer” or “UI designer” on the other. The software designer wasn’t just a graphic designer, nor was he just an engineer; he was responsible for the “overall design” of a program. For example, Kapor writes, Dan Bricklin was the “designer” of the original VisiCalc spreadsheet not by virtue of having made detailed choices about its user interface but simply by having invented the “metaphor of the spreadsheet itself.”
In a way, Kapor’s manifesto applies the auteur theory to software. Just as the movie critics who espoused that notion wanted to direct our attention to thinking about who was the true “author” of a movie — in most cases, they argued, its director rather than its writer or producer — so Kapor wished to see programs shaped by one creative individual who could push them in valuable new directions and keep them from losing touch with whatever vision drove them in the first place. Such programs would be consciously and deliberately designed by a trained individual who could think not only about the engineering and implementation detail but also about the overall purpose and goal of the program and how users would interact with it. Interestingly, Kapor held that the designers should know programming (“Designers must have a solid working knowledge of at least one modern programming language”).
Robert X. Cringely’s history of the PC industry, Accidental Empires, suggests that Kapor pushed to elevate the idea of software design because he was afflicted with a case of “impostor syndrome” — he felt guilty about his own financial success at Lotus and somehow that guilt was motivating him to try to turn his own haphazard career path into something more formal and legitimate. That idea is, like much of Accidental Empires, muddled, entertaining and a little bit insane. I think Kapor’s motivation was simpler and more forthright: he knew that many programmers distrust designers and feel that they know best how to shape their handiwork. But he also knew that teaming a designer with a programmer could work: he’d had a hugely successful experience creating Lotus 1-2-3 in collaboration with Jonathan Sachs. And he wanted to see if that approach could be turned into a model for making better software.
A manifesto is a call to action. Did Kapor’s bear results? In the years since, there have been a handful of programs established — like Winograd’s at Stanford — to provide formal training to career software designers. Certainly, as software has moved to the center of the business world, and as Web-based programs have entered the mainstream, the industry has grown more aware of the need to impose creative shape on its products. On the other hand, there aren’t many examples of design being elevated to the central role Kapor advocated. In most organizations today, a business person says “This is what we need,” programmers attempt to build something to meet that wish, and designers slap on an interface. Programmers and designers often remain in an “us vs. them” relationship.
So far, I think the biggest hurdle to wide adoption of Kapor’s software design model is that it’s been too easy for organizations to view the role of software designer as an added luxury cost for most projects. And there simply aren’t many people with the unusual combination of skills and passions to play that role well. A good auteur, in software as in cinema, is hard to find.
Is Kapor’s early-’90s prescription still relevant? Do we need software designers as a distinct profession separate from “software entrepreneur” and “software developer”? I still find the “Manifesto” a bracing read, but I’m curious to know how it sounds to programmers working in the trenches today.
[tags]code reads, mitch kapor, software design[/tags]
Post Revisions:
There are no revisions for this post.
By coincidence, I happened to download a program written by that very Jonathan Sacks yesterday (Picture Window Pro); while it is undoubtedly very good photo manipulation software, and comes with helpful tutorials, it would have been hugely improved by a UI designer. It has an interface only a father could love. So score one to Mitch Kapor.
I am always in two minds on this question, mainly as I have seen programmers who where capable of good design (and no I do not mean me). I also think the emergence of interaction design is a very good thing. Sometimes I think having these job titles is simply a good way to make sure someone spends a lot of time communicating with and thinking about the actual end users. Too many development organizations seem to think that allow developers to meet users is something to be avoided at all costs.
Sorry for the long comment… ;)
Some when in the middle of the century a computer was born.Then the big bang of software crisis had come. The overwhelming complexity of large projects blew the best minds of the industry. The man stood alone in front of the infinite complexity of life, which he needed to translate into code. That’s when the epoch of great confusion (as I call it) has started. Just as in case of bubonic plague the witch hunting had begun. The first victim was GOTO operator. It was crucified and burnt on the holy fire of “well managed code” religion by Dijkstra. That didn’t help much. The famous preacher was trying to burn CASE also, but fortunately he wasn’t listened to. The man was blamed for the problem. Irresponsible and undisciplined programmers were to blame for the God’s punishment – missed deadlines of the software project. After many more victims, the pursuit after Holy Grail of “good design” had started and the greate evil – the ghost of “elite-designer-ruling-over-slave-programmers” was born. The ghost is being best described in Kapor’s article and P.Brooks mythical-man-month book. It is pity that even people I respect the most as P. Brooks are actually believing in a an utopia of designers’ cast building the system without most of the time being programmers by themselves. To be more specific in criticism I give you my “good design” manifesto:-
2. The code is design. The problem you are trying to solve in your head or in papers, are existing solely in your head and have a very weak connection to real problems. Every one in the company including CTO and VP R&D should be active programmers that what will make them better architects. Don’t listen to people who don’t actually code
2. Design of the software is design of the company – The company illnesses will find their way into the software architecture. Build the “healthy” company and you will build “healthy” software. You want to build good software start with the company.
3. Deep understanding of domain problem you are trying to solve is essential. There’s no “architecture” in the world, who will build a decent telephony framework if the only thing he did before is an enterprise applications even if they were best-of-breed ones.
The bottom line is that programming and architecture design are non divisible disciplines and attemt to divide them will evntually hurt the software product not help it.
I think the issue is complex. More complex than Kapor describes. What is a software designer?
His description of software designer seems to me to involve two disciplines. Organization of the programmer’s tools constructed for a project into a complete and ergonomic whole (the user interface design – which hopefully makes the program easy to use) and the direction of what tools should be constructed and included in the program (which make the program useful). This second aspect has nothing to do with ergonomics (ease of use) but involves expertise in the particular area of concern that the program deals with. For spreadsheets it would involve all the features that a user would want in a spreadsheet program – not simply how those features are presented to the user. This would include expertise in accounting, bookkeeping, finance, and whatever other disciplines might be included in the feature set.
This second aspect is probably easily understood by programmers. Any programmer that writes a program for someone else asks that person what task is to be done. In a sense that second person is then a software designer helping to design the feature set of a program. Years ago something called “expert systems” was a rage. Programmers would try to build programs that were “designed” by experts in a particular area, the goal of which was to replace those experts.
The example of an architect as compared to an engineer doesn’t quite fit the situation, especially with the example of home design, which most people can relate to and understand. But what about task specific situations that aren’t as commonly understood? An architect can become an expert in restaurant design – an extension of the kitchen/dining room example, but what if an architect is asked to design a building to produce “widgets” that involve very unique steps in manufacture. A widget maker would have to be called in to give details of the process and provide input on problems that might present themselves as the design progresses. Who is the designer? The widget expert or the architect? What if there are problems of scale involved. A production engineer would be needed to modify the process to suit a large scale operation. Who the “designer” is in all this doesn’t seem clear cut to me. All have significant input in design, at least in the broad sense Kapor gives to the term “software designer.”
I don’t know how significant the film director example is in terms of a software designer paradigm. Movie directors have a signature quality to their work which in the programming world is often masked by the OS “style sheet.” The design of the OS cuts into that aspect of the software auteur. Looking at Microsoft’s new Vista OS and new Office 2007, it’s ironic that Office 2007 allows user choice in the specific look of the program – outside of that set from within the OS. Microsoft as usual breaks rules it sets for others.
Programs also usually have some task or tasks that must be done. What’s the “task” to be done by a film – other than make money and glorify the people involved in the film making? Maybe there’s a “message” involved, but that’s not something usually of concern in a computer program.
There is an area in programming that is comparable to film making. Games. The key to games is often not the expertise of the programmers involved. Sure it helps if they can build high speed high resolution realistic 3D graphics engines, but those aspects are usually common to the industry, or at least of fairly comparable quality levels. It’s the look and feel of the game that are key. It’s the pleasure, thrill .. whatever .. that it gives to the user, player, viewer that are important, just as in a film. Consider a game as simple as Tetris. Does anyone think that programming expertise was the key to the success of Tetris? The interface design? No and no. It was the brilliant design of the game itself. Its hook for users.
Ironically that aspect of design, the most creative aspect, seems to be missing from Kapor’s “software designer.” He recognizes the brilliance of a Dan Bricklin in creating the spreadsheet program but seems to leave out that feature from his “software designer.” I can understand why. It’s the designer of the mythical “killer app.” The program people didn’t know they wanted or needed until it was shown to them. Kapor was smart enough and lucky enough to take Bricklin’s killer app design and build it on an exploding platform – the original PC.
I had the fortunate experience of working at a telecom company in their usability lab. Working with the psychologists to set up usability experiments gave me some eye-opening experiences. One of the bonuses was that I was introduced to Donald A Norman’s book “The Design of Everyday Things”. His most scathing criticism an object is “it probably won an award.”
In any case, one of the major points in his book is that software fails because there is no direct line of communication between the designers/developers and the actual users. Both groups create their mental models of how things work. When the models agree, things work fine; when they don’t, there are problems.
I think Kapor’s implicit point is that a software designer would rectify this communication problem.
I’ve known and worked with a number of real architects in the past. I’ve also seen how some Schools of Architecture train their students. I’m not sure what a Software Design program would do, but a project-based approach would be a good idea. It’s an approach I’ve never seen in CS programs.
Back to architecture: Designing a house is relatively easy. His analogy works well here. It’s also why graphics designers tend to be the best choice for web design.
Designing a radical new building design, however, is a different story. In this situation, architects work far more closely with engineers than they do when designing houses. Most large software design efforts are closer to this situation since these projects tend to be huge unknowns; hard to understand, estimate, and design.
Architecture has inspired changes in this area via the pattern movement. Whether your opinion of patterns is good or bad, the effort is definitely worthwhile at a high-level design view.
There is a trend in many engineering schools to incorporate design programs. I don’t know if there is a similar trend in CS, but I would hope so. Kapor’s vision has not been realized yet. Though I’ve never seen it in practice, I think it could work.
While I agree with most of Boris’s points, I do take a bit of issue with the comment “The code is design.”
I’ve heard that too often to give it credence. The code is not design, it’s implementation. You can hope to extract a design from the code, but more often than not you’ll see a mass of implementation details.
In construction, there is a distinction between the architect’s plan and what is on the ground. As a building gets constructed, notes are made on the plan with the caveat “As Built”. “As Built” is a trade-off between the actual design and the reality of building something. In construction, such changes are documented. In software, that information is often lost and is almost never in the code.
Some people use “the code is design” as an excuse to slap things together with no plan for construction to begin with. The result is a mess that is buggy and extremely difficult to understand.
I’ve also heard “The code is documentation” too often to trust, but that is a separate issue.
The article sounds somewhat dated. Maybe in the 80s and 90s people thought Dan Bricklin’s invention of the electronic spreadsheet was “one of the crowning achievements of software design”. Perhaps it’s Kapor’s dual-use of the word “design” to mean the structure of the software and the user interface model. In a Naked Objects system, the two are the same. And in early desktop software. But in today’s multi-tier SOA systems, the presentation layer is but one tiny piece of the whole.
Design is meant to be easy to change. And implementation is supposed to be the final product. The problem with software is that you can only design once, but you must change the implementation forever (maintenance). So we end up changing what should be static. Contrast that with construction for example. In this case, you don’t change something. You tear a section down where your new design goes and then you put up new materials. In software, tearing stuff down can have unforeseen side effects.
What would be better is if there was a way to specify design and have the computer generate the implementation. Now, that would change things drastically in the computing community. Instead of building implementation directly, we would write code as possible algorithms that the code generator can use for its output. But the design would be easy to change. This area interests me so much that this is exactly what I’ve been researching this past year and am currently developing a project with this in mind. I wonder how many other attempts have been made and what ideas there are out there on the subject.
I thinks what confuses most is that there are better and worse programmers and the gap is just huge. Some programmers consistently will make better decisions than others. There is a “chemical X” which makes some people get insights infinite times deeper than all other people around them. Kapor is one of them. he actually has some very impressive achievements under his belts.
But then, in order to scale it, these men are advanced to “architect” positions and less “expensive” programmers are hired to work under their leadership in hope that in this way the company will get one’s talent “improve” others team members output. That’s crucial mistake, because the art of programming is not “scalable”, because of great complexity of software projects. It is a lonely wolf routine. Your best stake is to hire as many good programmers as you can and let them roll.
Design is a plan. And, to use an old army adage: “No plan survives first contact with the enemy. That’s why he’s called the enemy.”
Cleo wrote: “What would be better is if there was a way to specify design and have the computer generate the implementation.”
Yes, it would be nice, but I’m wary of things that sound like code generation. To have a truly useful tool, it would have to accurately reverse-engineer the design from the potentially modified results of the code generation. I have never seen this work on anything other than small-scale projects.
The few such tools I’ve tried in the past have been tedious to use, error prone, and generally unhelpful. Keep in mind that programmers don’t like making extra work for themselves. If it’s hard to use and doesn’t do a great job they’ll avoid using it. But, if someone eventually gets this to work, I’d definitely give it a try.
Dave: What I meant was something that would NOT be reverse engineered. You’d only work with the design. Never with the generated code much like no one works with machine code anymore.
I believe that we’ve addressed (at least in part) the issues that Kapor raised, but we’ve done so under two headings: user interface design and software architecture.
On the one hand, our industry is beginning to recognize that successful UI design is about communicating with a human being to support that person in the performance of some task. Organizing that communication around terminology, metaphors, concepts, and workflow that is natural to the task takes quite different skills than the technical skills of making the computer perform a specified action.
Similarly, successful software design requires thinking of larger issues (scalability, deployability, addition of future unanticipated features, etc.) that don’t arise from simply reading the functional requirements of the current release.
It is important to return to visionary documents such as Kapor’s, not only because they give us fresh perspective on where we are, but also because they can remind us of parts of the vision we may not have fully realized in our rush into the future. As William Gibson said (and O’Reilly has used as their tagline for a podcast series), “The future is here. It’s just not evenly distributed yet.”
You all need to invent your own thing and stop criticizing people and there things!!)