A Conversation with Ken Arnold, Part II

---

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.

Teaching Taste

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.

Learning Taste

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?"

Simplicity as its Own Virtue

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 getKnobs() method. JButton would have 10 methods, including getKnobs(). It would return a ButtonKnobs 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.

Discuss

Have something tasteful to say yourself? Discuss this article in the Cool Stuff Forum topic, Taste and Aesthetics

Resources

Frank Sommers interview with Jim Waldo, in which Waldo mentions taste, is at :
http://www.artima.com/intv/waldo.html

Ken Arnold mentioned the complexity of Swing in Part I of this interview:
http://www.artima.com/intv/perfect.html

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:
http://www.amazon.com/exec/obidos/ASIN/0385267746/

The Jini Community, the central site for signers of the Jini Sun Community Source License to interact:
http://www.jini.org

Download JavaSpaces from:
http://java.sun.com/products/javaspaces/

Design objects for people, not for computers:
http://www.artima.com/apidesign/object.html

Make Room for JavaSpaces, Part I - An introduction to JavaSpaces, a simple and powerful distributed programming tool:
http://www.artima.com/jini/jiniology/js1.html

Make Room for JavaSpaces, Part II - Build a compute server with JavaSpaces, Jini's coordination service:
http://www.artima.com/jini/jiniology/js2.html

Make Room for JavaSpaces, Part III - Coordinate your Jini applications with JavaSpaces:
http://www.artima.com/jini/jiniology/js3.html

Make Room for JavaSpaces, Part IV - Explore Jini transactions with JavaSpaces:
http://www.artima.com/jini/jiniology/js4.html

Make Room for JavaSpaces, Part V - Make your compute server robust and scalable with Jini and JavaSpaces:
http://www.artima.com/jini/jiniology/js5.html

Make Room for JavaSpaces, Part VI - Build and use distributed data structures in your JavaSpaces programs:
http://www.artima.com/jini/jiniology/js6.html

Talk back!

Have an opinion? Readers have already posted 4 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.