Article Discussion
Taste and Aesthetics
Summary: 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.
4 posts.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: February 18, 2003 4:54 PM by Brendan
    Posts: 408 / Nickname: bv / Registered: January 17, 2002 4:28 PM
    Taste and Aesthetics
    September 16, 2002 1:30 PM      
    "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," says Ken Arnold in this interview:
    • Carfield
      Posts: 12 / Nickname: carfield / Registered: September 16, 2002 3:19 PM
      Re: Taste and Aesthetics
      September 16, 2002 7:34 PM      
      Thx for the great article about software design. After reading the article, I have an immediately question about compatibility and software design.

      When we are adding new features to our system, we usually keep the old features for compatibility reason. For examples, JDK ship AWK in 1.0 and 1.1 time, so even now we have swing, which suppose to be better, we still keep AWT package for the one who need. In the article, the author argue that we should remove AWT. However I don't think this will happen as people like to keep more thing on hand.

      Similar story happened in .NET platform. Which microsoft try to make a language naturn platform which allow difference code, old and new, work togather. I personally feel that this will bring a lot of maintaining work in the future as the system at no style at all. However, people seem like this idea.

      I like to ask, as a software designer, he need to work for a software to take care compatibility issue, how can he still have a simple and aesthetics design?
      • Ken
        Posts: 9 / Nickname: kcrca / Registered: March 8, 2002 4:25 AM
        Re: Taste and Aesthetics
        September 16, 2002 11:04 PM      
        That's always tough. Your existing users will refuse incompatibilities, so things only get larger and larger. The JButton example I gave probably exists partly because of a desire for a certain compatibility. Over time this gives opportunities to new players to take your users. It's odd, but users will accept incompatibilities from another company to get their benefits, but they won't take it from you.

        One approach is to use separation. In the initial design, you break things up into good logical units. When you have a major new feature replacement, you add it in another place and give people some transition tools, but you do *not* (if you can avoid it) make the new tools directly compatible with the old.

        For example, if Swing had started with a blank slate and said you cannot intermix Swing and AWT stuff, some things would have been more painful, but overall it would be simpler. AWT would have worked in its own way. Swing would have worked in its. And you could, as a Swing user, ignore the entire AWT subtree. Under the covers there probably would be a lot of code sharing, and maybe some simple tools to translate (say) an AWT Color object into a Swing one.

        This would have been better if SWT made a separation between components and graphics (buttons vs. colors, for example) and put them in separate packages. Maybe then one could reuse the same Color object in two very different component models. Since they didn't, you might compromise by having a list of AWT classes that do matter in Swing. That would be a middle ground that might be reasonable.

        The point is that a user could say "I'm using Swing so I don't have to know about this AWT stuff." This reduces their effective surface area because a whole section -- hundreds of pages of doc -- can be dismissed in a single sentence.

        That's one idea, anyway. Accretion is the curse of success -- if nobody cared about your stuff you could change it anyway you wanted. But when you do something people like they make you stick to it until you're sick of seeing its warts. Maybe then it's time to find a project and let someone else live with the mess. :-)
    • Ron
      Posts: 1 / Nickname: rwelch / Registered: September 16, 2002 5:16 AM
      Re: Taste and Aesthetics
      September 17, 2002 1:31 AM      
      I just finished reading the second part of the conversation with Ken Arnold. Very interesting. Another article on subject of "Taste and Aesthetics", that in many ways seems to echo the same themes, can be found at:
    • Brendan
      Posts: 5 / Nickname: yow / Registered: February 18, 2003 11:44 AM
      Re: Taste and Aesthetics
      February 18, 2003 4:54 PM      
      I disagree with an implication that Ken makes about the relationship between internal and external simplicity:

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

      I believe that the *only* way to robustly implement simplicity in an extenal view is as a consequence of the internals... that way, all the generalizations of the external view that you could never have anticipated all come out right, without you needing to think about it (or at least, much more so than if they differ!)

      Another way of saying this is seeing the program as a "theory of the problem", and Occam razor says that the simplest (ie shortest) solution is the "right" one. Lots of fakes and hacks and mapping code make a longer solution - and so aren't "right". Occam's razor is very satisfying in itself - but it is more than that! The "right" solution generalizes well, and so pragmatically is better also.

      Example: before Copernicous, planetary motion was modeled with very complex models ("epicycles within epicycles within epicycles") - it was often slightly wrong, and they just added another epicycle. In other words, it didn't generalize well, because it wasn't the right model. Whereas the heliocentric view makes superb predictions - even if that particular situation had never been seen before! It sheds light in the dark places, instead of having to bump your nose up against every wall! "The sun at the center" is the true model - it is the reality.

      Having the same model internally and externally means that your code generalizes in the way that users expect. Otherwise, they will often be bumping their noses.

      There's one extra bit to this: you *can* write shorter code that is less readable... I think the "length" of code shouldn't be measured in bytes, but in "thought units". Thus, a for-loop in java is probably one unit... and a pattern (if you personally are familiar with that particular one) is also a "unit" for you. Whereas some clever bit-shifting is probably several units (unless they are so second nature to you).

      Yes - the simplity of a particular piece of code is subjective; it's not an absolute. In Bayesian theory, this is the "prior expectation" that a particular theory is true. Older, experienced developers will have different priors from younger ones - partly because they have more experience with the typical problems; and partly because they are more familiar with the older ways of solving them.

      The evolution of languages and patterns and idioms is actually the evolution of the priors behind the language - in other words, they make some things simpler to express, and some things more complex. Typically, this makes the "common problems easier to solve, and the rarer ones possible". It also means that the best way of solving an old problem may change, as the priors change. What drives this evolution? Well, the patterns that do better at modelling the problems that people typically come across get used more (in the long run). Of course, market-like factors influence this as well, like what gets promoted more, what makes sense in terms of what most people already know, and what problems are most common, what group of people communicate better with each other, where are the really smart people and are they able to communicate their ideas.

      Summary: The shortest solution (in terms of your thought-units) is the "right" solution, in the sense that it best generalizes to cases that you would never have anticipated.

      To reap the generalization benefits of this, your code needs to be internally simple in the same way as it is externally.

      Yes, sure you can be clever, and make it *appear* differently (and this is sometimes necessary) - but are you clever enough to anticipate *all* the generalizations of the external model, and make your internal model match up with it? Or in practice, will you be forever patching it up, as bug reports come in? (that is, assuming that this code is exposed enough to get exercised in many different ways).

      The *only* way to robustly implement simplicity in an extenal view is as a consequence of the internal view.