Sponsored Link •
Ken Arnold, the original lead architect of JavaSpaces, talks with Bill Venners about the role of taste in design and the importance of designing with the user in mind.
Ken Arnold has done a lot of design in his day. While at Sun Microsystems, Arnold was one of the original architects of Jini technology and was the original lead architect of JavaSpaces. Prior to joining Sun, Arnold participated in the original Hewlett-Packard architectural team that designed CORBA. While at UC Berkeley, he created the Curses library for terminal-independent screen-oriented programs. In Part I of this interview, which is being published in six weekly installments, Arnold explains why there's no such thing as a perfect design, suggests questions you should ask yourself when you design, and proposes the radical notion that programmers are people. In this second installment, Arnold discusses the role of taste and arrogance in design, the value of other people's problems, and the virtue of simplicity.
Bill Venners: In an interview with chief Jini architect Jim Waldo, Frank Sommers asked Waldo how he assembled such a talented team of people in the Jini group, Waldo responded, "Much of [building a good team] is just finding people who have the right sense of aesthetic -- a lot has to do with taste, and a desire to keep things simple and elegant." What does taste have to do with design?
Ken Arnold: When you are faced with a design problem, it is important to ask the question, "What does the user want?" The answer to that question has a lot to do with taste.
It's funny. To some extent you can answer that question empirically. You can ask users what they want. But sometimes people say they want something when they really want something else.
You cannot apply your understanding of human beings in a purely rational way, because human beings aren't purely rational. In the end, you have to use some sense of judgment. You may say, "People think they want to do this, but frankly they're wrong." Or, "People don't realize this is a good way to approach it, but if I present it to them they would get it." And those are intrinsically arrogant statements. You are essentially telling users that in this area, you know more than they know about what they should want. But that kind of arrogance is a form of aesthetic.
Say you have a guy who paints your house. He'll paint it any color you want, but he doesn't want to paint something that looks ugly. If you suggest one color, he may push you the other way. Eventually, since you're the boss, he'll do it if you insist. But his sense of aesthetics leads him to tell you, "You think you know what you're doing, but I actually have more experience in this area. I know better how to implement what you say you want."
That is the sense of aesthetics required to design things. Your sense of aesthetics could be right or wrong in a given case, but you must have confidence in it. You must trust your interpretation of how irrational human beings will actually do something and what they will actually need.
Bill Venners: If you have taste, can you teach it? If you don't have taste, can you learn it?
Ken Arnold: Whether or not someone can learn taste depends on what kind of person they are. Some people have a really bad sense of taste. Other people have no sense of taste whatsoever.
People who have no taste don't consider aesthetics at all. They say, "Oh, I'll just add a method that does this. I'll just add a class that does that." If you talk to them about aesthetics they go, "Huh?" It doesn't make any sense to them. These people might be wearing polka dot pants and striped shirts at the same time, and there's nothing you can do about it. I don't think these people are trainable, though you can potentially improve their sense of taste. I've known a couple people who one day woke up realizing that taste mattered. But it is hard to teach taste to people for whom taste is not an important factor in life. It's a tough sell.
People with bad taste, on the other hand, are much easier to train. Such people have a sense of aesthetics, but they have a different set of values that they apply to those aesthetics. You can try to convince these people that their values are not optimal, that they can look at things another way.
It is a lot easier to convince someone with bad taste to look at something differently than to get someone with no taste to notice something they don't see in the first place. If you are color blind, you can't do anything about it except work around that problem. But if you aren't color blind, yet you like to mix really bad colors together, you can learn what a good color combination is.
Bill Venners: How do you learn what is good and tasteful in design?
Ken Arnold: Some people have a natural sense. Other people have to learn. But to a large extent, what people have to learn is to value other people's problems.
Taste is a very personal thing. There is no textbook. When people ask me about books on object design, the books I hand them have nothing to do with object design per se. I commonly recommend The Design of Everyday Things, by Donald Norman. This book promotes focusing on usability in the design of doors, teapots, and faucets -- everyday things. If you do that for objects, you'll have the idea.
Again the questions are, "What is the user coming at the problem with? What are they trying to accomplish?" Most people who have what I call bad taste are talking about themselves. When I express things in bad taste, which of course I am not immune from, I am usually talking about myself. I am not integrating my understanding with other people's understanding. If you can merge those together then you can acquire good taste. So teaching people taste is mostly teaching them how to listen and how to put themselves in someone else's place.
Instead of thinking from the implementation out, people need to think from the user in. As a designer, you may have two data structures that the user could merge to get a result, but do you understand that users don't care about your data structures? They just want to get the result. That is a revelation for many designers. Someone may have very good aesthetics if the problem is how to merge two data structures to get a result. But you can show them that that is not the question. The first step on the road, which many people miss, is asking, "What is the other person trying to do?"
Also, to me simplicity is its own virtue. Many people don't really understand that. If you make something big and complex, it will be hard to use and understand. If it has a large surface area, many methods and classes, the interactions of those things will continuously lure people even if you think they shouldn't. People will wonder, "If I make this method call, how will that affect this other thing?" Those two things may seem obviously unrelated to the designer, but users come up with all sorts of weird models about how things work together. That is partly because people tend to make those weird models, but they may also have an experience of calling some method that seemed completely unrelated to something else and having a result they didn't expect.
Users don't care about what the designer does. They care about what they do. If every time you drove a car, you had to learn the meaning of 100 knobs, the whole system wouldn't work. Simplicity comes from tuning down the tasks required to drive the car into a certain set of understood paradigms and tools. Yes, there are many people who would love to pull up the hood and start tinkering with things. You can let them, as long as that is all under the hood.
There is nothing wrong with having all those knobs. I mentioned the complexity of Swing before, that
JButton has more than 200 methods even though most of the time people
care about maybe five of them. My solution would be to design the system so that it had a
JButton would have 10 methods,
getKnobs(). It would return a
object, which lets you play with all the little ditties if needed. Then
JButton's surface area to a newcomer would be nine methods plus a way
to get under the hood.
Simplicity has real value on its own that makes the system more usable. It's the difference between reading a 100-page manual and reading a 500-page manual. It is more than five times the size.
Bill Venners: I think of simplicity as a virtue because the client for whom I am designing is a human being, and simplicity helps human beings. I see simplicity as a virtue in the context of the client. What exactly do you mean when you say simplicity is its own virtue?
Ken Arnold: Some people view simplicity -- and again, I mean the external simplicity, the user's view -- as something that happens if their system is internally simple. I am saying you should strive for external simplicity on its own.
Just like you should strive for efficiency or clarity, you should strive for simplicity. And returning to taste, striving for simplicity requires that you make choices. You have to say to the user, "You know, frankly, you think you want to do this, but you really don't. And if you really do need to do it, come back and beat me up. Show me why, and we'll do it later." To achieve simplicity, you sometimes have to say, "You think you want this, but you're not quite right." That is arrogance, the arrogance of taste.
Frank Sommers interview with Jim Waldo, in which Waldo mentions taste, is at :
Ken Arnold mentioned the complexity of Swing in Part I of this interview:
The Design of Everyday Things, by Donald A Norman, the book that
Ken Arnold said he suggests to people interested in books on
object design, is at Amazon.com at:
The Jini Community, the central site for signers of the Jini Sun Community Source License to interact:
Download JavaSpaces from:
Design objects for people, not for computers:
Room for JavaSpaces, Part I - An introduction to JavaSpaces, a simple and powerful distributed programming tool:
Room for JavaSpaces, Part II - Build a compute server with JavaSpaces, Jini's coordination service:
Room for JavaSpaces, Part III - Coordinate your Jini applications with JavaSpaces:
Room for JavaSpaces, Part IV - Explore Jini transactions with JavaSpaces:
Room for JavaSpaces, Part V - Make your compute server robust and scalable with Jini and JavaSpaces:
Room for JavaSpaces, Part VI - Build and use distributed data structures in your JavaSpaces programs: