The Artima Developer Community
Sponsored Link

Perfection and Simplicity
A Conversation with Ken Arnold, Part I
by Bill Venners
September 9, 2002

<<  Page 3 of 5  >>

Advertisement

Bill Venners: Simplicity is a design virtue, but can a design be too simple? If you eliminate some feature in the name of simplicity that is truly useful to most users, you've actually made their jobs more difficult. Since you didn't provide that feature, they have to build it themselves or do without it. How do you know how simple to make things?

Ken Arnold: Yes, at some point a design is so simple it doesn't work anymore, right? I think the fundamental way you get simple, yet sufficient, systems is to ask yourself some questions. First, what does the user need to accomplish? Let me back up and explain what I mean by user. I have this really weird radical notion. Every great idea starts off with an absolutely radical notion. I am immodest enough to think I have this great idea. And the radical notion that founds it is that programmers are people. Now if you accept this premise, then the next step is to say that designing tools for programmers, including languages, APIs, and compilers, is a human factors problem. And so we should ask the same kinds of questions that people ask about GUIs [graphical user interfaces]. Is it easy to do what you need to do? Is it natural? Are simple things simple? Are complicated things complicated? Are dangerous things hard to do? Are common things easy to do? Are similar things done in a way that is naturally similar to the person?

You start asking all these questions. And if you do that right, like with a GUI, you come up with something easy to use. It may be rich and complicated, but it has an easy starting point and easier mechanisms to learn things.

However, the more common way to think of design is, "What can I, the designer, do?" instead of, "What does the user want to do?" For example, we could have done many things with JavaSpaces, but our capabilities were of no value. It is the user's desires that were of value.

The questions I fundamentally ask are: What do users want to do? What do they have in hand when they want to do it? What kinds of information do they have to accomplish this task? And how do they think of this task?

Also, since my system will have more users than implementers, it is quite all right to make the implementer's life complex to make the user's life simple. People often say, "Oh, I will design it this way, because I have this kind of data structure and that kind of data structure, so I'll just allow people to merge them together to get this result." But the real question is what does the user want? It may be easy for you to put these two data structures together and hard for you to do what the user wants. But if you don't do what users want, then they will have to do it themselves. If they do it themselves, then you can expect they will do so 1700 different times on top of your API with more bugs and more complexity. The real reason RMI is easy compared to CORBA is because of that attitude, putting what users want first. They want to invoke a method. Okay, how do you make invoking a method as natural as possible without pretending things that aren't true? Well, they want to pass in actual objects as parameters. OK, but the runtime figures out how to get objects to the other side, not the programmer.

<<  Page 3 of 5  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us