Find Part 1 here.
RF: Within some of the analysis that I’ve read of the manifesto, there is discussion around the natural disinclination (or the natural distrust) of people in the engineering field towards those in the design field. This trend persists, obviously, but has it gotten worse?
MK: I don’t know if it’s gotten worse. Based on just my experiences, I don’t think it’s gotten better. I mean, except insofar as there is a recognition, albeit sometimes a grudging one, that it is regular people who use the stuff, and that the more self-aware engineers understand that their preferences as to how to do things are not the ones that should be automatically applied.
MK: You used to fight that all, “What’s the matter with this? I like this just fine.” I think you hear less of that but you don’t – I think there’s still a distrust because the engineers will go, “Well these people just don’t understand how things work.” Then there’s also problems just of communication, of designers and engineers not speaking each other’s language, not having kind of a common framework. So even when there’s a good designer and making valid points, if there isn’t a common language they won’t be understood and they’ll be disregarded.
RF: Have you seen examples of teams that are able to communicate appropriately?
MK: Well yeah. Well the ones that I’ve been involved with, it’s hard but I’ve seen some successes. Some really great engineers have much more of a design sense and an openness to it, and others don’t.
RF: In the manifesto you said computing professionals themselves should take responsibility for creating a positive user experience. Once again we’re back to the user experience not being –
RF: – but you were seemingly not just advocating for the software designer, but for engineers to step up.
MK: Yeah, because what they do is part of a larger whole. An over-focus on their particular specialization actually hurts the greater undertaking.
I mean, it’s just sort of a standard thing in business, like the purpose of the sales force is to sell stuff. It’s a problem of a local maximum. The sales force needs to understand why it’s selling things and how much, and don’t oversell. Well, don’t over-engineer and understand that you’re part of a team where it’s the value being delivered to the customer that is the important criteria, so there’s a kind of an insularity in engineering. Look, some engineers, they just have great development skills and low social skills. They shouldn’t be asked to do what doesn’t come naturally and they don’t want to do, but they also should understand that they’re yielding power and responsibility for certain things. They’ll have less power as a result of that.
RF: And that’s probably best understood on both sides of the equation, on design equation as well.
MK: Right. Yes. That’s right. You know, the other thing I would say is that in most software development organizations and projects I’ve seen, the power relations that are always very implicit. I mean, there’s an org chart but the decisions that actually get made never happen by an org chart. But they’re also just not very explicit, things sort of happen. Unless you’re in the project day to day, you can’t even tell. The problem is that that tends to – those systems, when there are these implicit power relations, there’s a fragility of the organization’s functionality that results because if there’s a problem, or a dispute or a disagreement, because everything is implicit people don’t have the tools to actually talk about engaging a good process for resolution. This is a subject I don’t remember talking much about in the manifesto, but part of the issue of producing good software is – good software is produced by good organizations. By organization I mean everything from the initial corporation to an open-source movement. They have very different organizational structures, more centralized, less centralized, you know, and so on and so forth. But they all have power relations, they all have governance, they all have –
RF: In a sense, maybe not explicitly within the manifesto you’re not arguing for organization but you are implying your vision at the time of that alignment between the sole author –
MK: Yeah, I mean, when I was talking about the heroic. But there’s a deep mystery which is great things get done when there’s highly productive collaboration, and great breakthroughs in innovations tend to come from individuals or very small groups. How do those things fit together? That’s a deep mystery. I think that that’s something that gets wrestled with but never solved.
RF: So there’s no formula, it just happens somehow?
MK: I certainly believe there’s no formula. Whether there are even principles that you can rely on, even though the principles may sometimes be in conflict with each other, is itself I’m not sure.
RF: You, as an entrepreneur, have dealt in situations where you’ve got huge wide distributed teams working on things, and also very focused, very small teams. Where do you feel more comfortable?
MK: I like the small teams better but I think it’s also good to work outside of one’s comfort zone. Look, software is hard to do, still, and seeing the OSAF team and me being delicately pinned like a butterfly to the – you know – and dreaming in code was really quite painful at times because I look at that and go, “Oh yeah. Didn’t really know what I was doing there.” and had paid the price.
Do I like small teams or large things? Right sizing ambition is incredibly important. That was one of the major problems with OSAF. This is in this sort of organizational leg of the software tripod, if there’s design and development and then how you organize the whole thing. Because we were simultaneously trying to innovate very dramatically, and also do something that could replace a product in a mainstream category. It was just too much to try to do all at once. It was sort of like – and this only became apparent to me and us in hindsight. Knowing what I know now – of course it was different, there was a real learning – I haven’t done any real hands-on guiding of projects in rather a long time and so my eyes were bigger than my stomach. One of the lessons there is if you want to do something that is highly innovative, don’t also try to assemble a large team to do a big thing. That’s a very bad mixture, almost doomed to failure. I’ve been running into people that used to work at General Magic, that was a similar experience for them.
RF: In terms of kind of self-representation in the manifesto and your experience since then, do you see yourself in your role on larger teams or smaller teams as something resembling a software designer, or trying to –
MK: I hope so. If not that, I’m not sure what.
MK: I mean it’s a product design. I’m an entrepreneur so I have the responsibility for the undertaking as an enterprise or project either for-profit or non-profit. I’m also typically the financier because, although not necessarily the sole financier, I’m in the fortunate position of being able to do that. The thing I love to do the most and my very significant value-add is in the overall conception of the product design. I have found that actually products other than very little ones – like the Foxmarks extension – are sufficiently complicated and I’m sufficiently busy that things come out much better if I delegate very heavily to keep people I work with to do the details of the design and to work it out. So I’m probably reinventing what other people have done all along. I’m trying to figure out how to leverage myself. You know, the Foxmarks extension, Todd and I designed it. But I not only had what the concept should be but there were a lot of discussions about, “Well what’s the overall experience?” So the idea that it becomes invisible once you install it is one of its principal affordances. I was just incredibly insistent that as a bookmark synchronizer it should just get out of your way; you shouldn’t even know that it’s there. We did a lot of things to –there were a lot of decisions that followed from that, both in terms of how it actually worked in the background, and its visual appearance. I was driving that so if that’s not design, I don’t know what is.
That was the role that I had in Lotus 1-2-3. That was the back-story – and I don’t remember how much of the back-story is in the manifesto. Probably not. It’s probably elsewhere.
RF: From your collaboration with Jonathan Sachs?
MK: Yeah. The back-story is Sachs and I did this product, not in an introspective kind of way. He did what he did, and I did what I did but it was like words and music. I mean there was a very distinct separation of roles there. I was the designer. So the problem I had was after Lotus became very successful, people didn’t understand what I did. Not in my role as the entrepreneur or CEO but in the conception of the product. They thought, “Oh, so you did the marketing?” because there wasn’t a pigeonhole for what I did. I’d say, “No, I didn’t write any of the code. No, I didn’t do any of the technical architecture. In fact, I never looked at any of the code. I don’t know what data structure Sachs uses to represent the formula change. I have no clue.” People were just not – they could get as far as product marketing where you wrote what the customer requirements were. I said, “No. That was part of it.” But I actually said, “It’s very important that there be very tightly integrated graphic because people have their spreadsheets, they got the numbers, they got the graphs.”
In the previous generation with VisiCalc and VisiPlot, it was two separate products, a very laborious process that actually involved writing out an external file and rebooting your computer for the VisiCalc’s copy protection to load up VisiPlot, and then exporting the external file and making the graph. I said, “This is nuts.”
I said, “The opportunity is here’s the spreadsheet, make the graph.” But then, I mean a lot of things, I didn’t just leave it there. It was, “Well, okay. How do you do that?”
So the genesis of the design manifesto was really an attempt to legitimize myself and to explain to people what I actually did in the product. I was doing it in 1983 and 1982.
RF: You’d been doing it for a decade by the time you wrote it and –
MK: That’s right, and now I’ve come back to it. In fact, it goes back even further than that. So Lotus was like 1982 – was when we were developing the thing. I first put my hands on a computer 15 years before in high school, 1965, 1966. It was immediately apparent because I was very good at math and I loved numbers, and had tons of facility. But I really sucked as a programmer in comparison with people that were good programmers.
I knew that. It was just evident to me. But I sort of felt like this affinity and that I had something to offer. It wasn’t until PC’s came out, so it was the mid-1970’s – that I began figuring that out. But it was the being talented at things computer-ish but not in the act and art of actually writing code. That’s what essentially gave rise to all this.
RF: One of the questions you ask yourself in the manifesto is what makes something a design problem, and in doing so you refer to that intersection between technology and human purpose.
MK: Yeah. Yeah.
RF: Do those things still hold? Are those still kind of the two qualifiers for whether or not a design is really where that’s going to get solved?
MK: As far as I can tell. That’s kind of like a postulant. You evaluate its utility based on assessing the consequences of holding that postulant. It’s not true in and of itself. It is true or it has value insofar as what you conclude from that postulant and everything else you believe kind of accords with things. So I just did a generalization. I asked myself. I looked at industrial design, graphic design and the then other forms of design, and architecture and software design. I said, “What do they have in common?” It seemed to me, obvious on inspection, as they say in mathematics, that in each case there were some material or immaterial substrate stuff – bits, atoms – that were the media within which creations were being realize of some kind. But they were all directed and driven by what it is people wanted and needed. I mean it just seems so obvious. So the answer is how could it not be true? I guess the only thing to be said is, well there could be another perspective that is so much more relevant that you would say, “Well that’s true but not very interesting.”
It’s axiomatic is what I’m saying.
RF: We had a gentleman come in last week, a guy by the name of Brett Victor. He contends there’s actually no such thing as interaction design, that there are matters of input, which is industrial design, and there’s a representation, which is graphical design. Everything else should be – those two should take care of everything else.
MK: He sounds like he should meet B.F. Skinner or converse with the ghost of B.F. Skinner. It’s all inputs and outputs. There’s nothing going on in the middle. It’s sort of neo-behaviorism.
MK: So what I would say is that’s not even worth a cup of coffee. The other interesting thing is that when it comes to – I mean, maybe he’s saying something more interesting than that.
RF: Another point you make in the Manifesto: software is hard. It’s hard to build and it’s hard to use. There is a certain vogue for simplicity for making things smaller, like you said, curtailing – not ambition maybe, but –
MK: Small pieces loosely joined. Yeah. Right. That’s good.
RF: Do you see that as potentially solving some of the issues around –
MK: Just for a while. I mean the fact of the matter is that operating systems are big however you build them, or don’t build them. I mean, you know, some needs are just large. But if you can satisfy a human need by doing something small, or connecting a few small things, that’s great. That will solve a bunch of things. But there are some needs, like cities and big public civic works and power distribution, and how we’re gonna manage climate change. I mean there are big problems and issues, the vogue for simplicity can be overdone. I mean, small is beautiful but fine – Einstein said, “Theory should be as simple as possible but no simpler.” So that’s probably the operative wisdom about that.