The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

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

Page 1 of 5  >>


Ken Arnold, the original lead architect of JavaSpaces, talks with Bill Venners about the myth of "the perfect design" and discusses ways to achieve simplicity in designs.

Ken Arnold has done a lot of design in his day. While at Sun Microsystems, Ken was one of the original architects of Jini technology and was the original lead architect of JavaSpaces. Prior to joining Sun, Ken participated in the original Hewlett-Packard architectural team that designed CORBA. In Part I of this interview, which will be published in six weekly installments, Arnold explains why there's no such thing as a perfect design, suggests questions you should ask when you do a design, and proposes the radical notion that programmers are people.

Bill Venners: I once heard you say there is no such thing as a perfect design. Could you clarify what you meant by that?

Ken Arnold: There is no such thing as a perfect design for a couple of reasons. One is that all designs take place in context. You are trying to solve a particular problem. Although you might state in a general way, "I am trying to put together a linked list container," the fact is that linked list will be used in a particular context. And whatever design trade offs you choose to make the linked list reasonable for that context will be bad for other contexts. For example, in your context, are there more insertions than deletions? Is there more reading than modification? Depending on the answers to those questions, you might make certain optimizations rather than others.

Another issue is who will be programming with your linked list. Are you giving it to a group of rocket scientists who you can trust will do things right 98 percent of the time? Of course, you'd be wrong, but you could hope they'd be right most of the time. Are you handing it to relatively inexperienced people? Or are you handing it to people who, despite being very experienced, aren't focused on how to use the linked list? Instead, they are focused on some other problem, so their understanding of the linked list will be casual. If so, you have to design to prevent errors. Designing to prevent errors can make your job more difficult. You may have to trade off error prevention against functionality, or at least ease of use. So part of the reason no perfect design exists is that no matter what you do, you end up making one design trade off over another. You make choices that are right for your context, but bad for some other set of circumstances.

Another reason, which is in a different category, is that if you try to create a perfect design you will expend a huge amount of effort. You will go through all sorts of behavior patterns. You and the architects meet and think about this perfect design mightily. And you argue for hours over, say, whether next should be synchronized. It is a vast sink of time. The difference in effort between delivering something perfect, as opposed to something good, is significant. It just isn't worth the trouble in 98 percent of the cases.

And then there's the problem of predicting the future. Whatever you design for, whatever set of trade offs you choose, no matter how hard you work at it, your linked list will be used in ways you didn't expect. Perhaps you thought there would be more modifications than reads, but it turns out you were wrong. If you over commit to any of those directions, you can hurt your design.

The best that people can reasonably hope for is to put forth an appropriate amount of effort and get a good design that is sufficient. Your design should do as little as it can to get the job done so you can add the right thing when you discover what that right thing is.

Page 1 of 5  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use