a (very long) conversation with mitch kapor (part 1)
A little more than a year ago, I sat down with Mitch Kapor to talk about the legacy of his Software Design Manifesto. The conversation was part of some research I was doing on a larger topic, one which I don’t think I’ll have time to return to now that I’ve left Adaptive Path. Before my first day at Plinky, I wanted to clear the decks, and get the transcript of the conversation out into the world.
As always, Mitch has plenty of wonderful things to say. There’s a significant history lesson, some pointers on entrepreneurialism, and some very frank perspectives on the principles of design. I’ve edited it a bit for focus (mostly mine, I’m a conversational interviewer, and tend to let topics wander) and broken it out over a couple posts, which I’ll publish in the next few days. I hope you find what Mitch has got to say as valuable as I do.
Interview with Mitch Kapor (part 1)
Mitch Kapor: By way of context, you know, there’s an upcoming conference or workshop being convened by Terry Winograd and people from d.school on sort of software design – they’re calling it technology design now – 15 years later. Do you know about this?
Ryan Freitas: I know that it’s happening. I don’t know all the details about it.
MK: It’s happening in I think the first weekend in June, bringing together many of the people who were there at the original conference. My sort of manifesto was one of the drivers for that conference.
RF: Esther Dyson’s – was it PC forum or –
MK: Well that’s why I gave the talk about the paper. Terry had independently been working on an approach to design that is shared a lot in its perspective and had some differences, but he was writing things, also. He organized this conference with NSF money. He was on his own track. That track became the d.school eventually –
MK: – but my manifesto was an important stimulus. So I’ve been thinking some about this whole subject in preparation for this conference, and then I gave a talk just a week and a half ago for – what the hell were the name of those people – DSR, Design Science Research, which is another thing coming out of academia with some NSF funding for the Science of Design, that has some similarities and some profound differences, the main one being my approach in the manifesto – and since then – has been to look at things from a practitioner’s perspective. They’re looking at things from an academic perspective.
So… I’ve been thinking about these things. The timing of this interview is good because until I started thinking about things, I would have even less to say than what I have now. So I re-read the manifesto in preparation for all this, and I was struck by several things. The first is it really is of the form of a manifesto and a call to arms, and it’s intentionally provocative in that kind of way. If I were writing something today, I might not write it that way. That came out of my personality and my situation in the world and my history, and sort of my personal narrative as it came out of the situation itself. So that manifesto-ness of it – you could say, “Well was it necessary to write a manifesto?” No. There was a situation, and then there was my response to the situation.
The manifesto came out of a chemical reaction between the two. But in re-reading it, I think the situation that I was describing, the problem, is still very, very much present, which is that software is too hard to use. That is a symptom of a deep problem that has to do with the marginalization of design, then and now.
RF: So you think that trend persists?
MK: Yes. I think there’s been some interesting change and interesting progress, but in the main I don’t see a fundamental change.
RF: In talking about the principles to which you though good design and good software aspired, you used classical principles of architecture Vitruvius’ firmness, commodity, and delight –
MK: Right. Right.
RF: Do you feel that, 15 years on – with the advent of networked architectures, applications being rolled out as services – does the architectural metaphor persist? Does it still hold? Can you still use that as a foundation?
MK: Oh, absolutely. I mean, you wouldn’t expect 10 or 15 years of change to undo criteria that are held up for a couple of millennia, would you?
RF: No, not necessarily.
MK: In fact, I think – I thought you were going in a slightly different direction –there’s a perspective that I think is a valuable one to look at the kind of enabling infrastructure on which end-user or applications and services are built and to look at the evolution of those enabling infrastructures. So today we have an infrastructure, and it itself is changing with things like AJAX and so on.
MK: The enabling infrastructures in certain ways more easily afford the realization of good designs than they did then, although the new enabling infrastructures also have some issues and problems. I’ve been thinking a lot about PC client applications versus Web applications. It’s kind of like when there’s a fundamental change in building materials, like when in the late 19th century we started using steel to build commercial buildings, not just wood and brick. That was a big revolution, you know, the skyscraper, and you could do things. Steel was an enabling infrastructure for the most prominent symbol because there are other parts to it. There’s the Otis elevator and so on. So lots of things improved but some things didn’t improve in virtue of the enabling infrastructure. Because I’ve spent so much time in the past six years on Chandler, and there is now both a desktop client and a Web client, it’s been a real opportunity to have a lot of experiential learning. The cost of development is much larger on the desktop client. Web apps are just plain easier to do by a significant factor.
RF: Okay, so it’s the point of entry for someone who wants to get an idea –
MK: It’s a lot lower and also your total project cost is much lower. But the kind of nuances you can get on the desktop client are still not there on the Web client, which may or may not matter. They may matter or they may not matter. I mean it depends. The Web infrastructure obviously isn’t fully evolved, either.
RF: There’s an ongoing debate right now whether or not Web applications should look like desktop apps, or if they should just look like Web applications.
MK: Right. Not only in addition to what they should look like, what’s the finder? In other words, you need a metaphor or metaphors for organizing when you have multiple documents, assuming if you’re still producing documents and sharing them. But, you know, content – objects – how do you organize and find them, and do you use a kind of a Google file. You know, there’s a search box. Or do you use a finder style window of a hierarchal folder? I’ve seen people do both in Web apps, and I think the jury is still out but I have my own views.
RF: To switch back to the theme of the manifesto, you argued for the software designer as champion of the user experience, and –
MK: Yes, but I was actually making a bigger argument that I would step back from now. I wanted to not only – first of all, term “user experience” is a more recent vintage than when I wrote the manifesto. It’s emerged. We had user interface – we had UI – but we didn’t have UX as a term of art, right? I think actually UX, that’s a good thing in the cause of design because it is more holistic. It talks about the whole experience, not just the interface. So if we were talking about a car, the difference is the interface is steering wheel and the pedals and what’s on the dashboard. But the experience is what it feels like to drive the car, which is a more holistic experiential attribute.
That’s a good thing to recognize that that matters, and to empower people in a role of being the champion of that. That is one of the good things that’s happened in the field. I was actually advocating something else more than that, which is to put software designers in charge of the whole project, which hasn’t happened which I don’t think is what I would want to have happen now. But I know what I meant then.
RF: What did you mean?
MK: Well, I was borrowing from the heroic model of building architecture, like Frank Lloyd Wright. So if you wanted to get a house built, you cam to Frank Lloyd Wright and you took the commission. He was in charge. In fact, he’d send you off to Europe and say, “I’ll let you know when it’s done,” and he would design the whole thing. Not just the house, but the furniture.
The sub-architects and all the engineers, they listened to him or, I assume, he’d fire them. He was a prima donna and his buildings actually, you know, scored higher on delight and lower on firmness and commodity.
RF: Do you think you’ve stepped away from that idea?
MK: Well here’s the thing. I so much wanted kind of – unconsciously, the manifesto is suffused with borrowings from that archetype. What I think is wrong with that is that doing good software, or for that matter digital content, requires the close collaboration of people with very different and complementary skill sets. Just because there’s previously been a tyranny of the programmers over the designers does not mean the solution is to invert the hierarchy and put the designers in charge of the programmers. So the open question is what are the best models that embrace and celebrate design, and in a way that appropriately involves the people who are gonna use it. Now you’ve got the hardcore Scandinavian participatory design people. You’ve got the open-source movement. You’ve got some very unresolved issues about the different kinds of collaborative practices that will result in good end products. But I don’t think putting the designer in charge in a heroic kind of way – that heroic aspiration – is the right model. I said that in the manifesto, but more than that it sort of under-girded a lot of things I was saying. So that’s what I was really advocating, and that hasn’t happened.
One more thing that hasn’t happened, which is that while I like UX a lot, the typical user experience guru or champion, that person’s responsibilities are not the overall conception of, let me call it, the product design or the service design. Like it’s more that comes from somewhere, and the user experience person is a key person in ensuring that there’s a good user experience for that thing. But that thing, whether it’s a Web word processor or a social network, or any of the new things, those things ought to be designed, too. I mean they are designed, but oftentimes not in a usefully self-conscious kind of way. Where are the designers of those things? Where do you get trained to do that if you want to learn to do that? The answer is we’re no further – well, not much further along than we were 15 years ago. Modula, or whatever good things might be happening in the d.school, which I have not investigated. It’s a grand experiment with that. That’s its aspiration.
RF: To be able to produce those kinds of individuals?
RF: And you spent a lot of time within the manifesto talking about what you think would be necessary both from a training perspective, from an expertise perspective and from a work environment perspective –
RF: – to facilitate the software design. The idea that a software designer would be at least somewhat proficient as an engineer, was kind of a cornerstone of what you were talking about.
MK: It was, and I think that some UI/UX people have some technical facility, but you can’t assume it and it’s probably less frequent rather than more frequent. That’s because the training isn’t there.