Great Design

I want to write something about GreatDesign. In my opinion, there are three primary ingredients to all great designs. It's important to realize that a system can be anything. If it is a language or even a class, the user is a programmer; if it is a word processor, the user is the person creating a document.

The system is a path of discovery. The system reveals itself through ProgressiveDisclosure. In other words, a user can progressively learn as much detail as s/he wishes to. S/he need not understand the system entirely to start using it productively. The system has multiple layers. Some users may dive into deeper layers while others are quite satisfied with the very outer layer. This is okay because the user can be effective in any of these layers. Most great systems grow with your understanding of the system. If you become good at something you are rewarded with an even better way to perform this task. For example, you can program effectively without learning about blocks. Once you really understand blocks, it changes your view of those parts of the system you have already learned. This doesn't mean you should make your system tricky -- in fact, that would be almost the opposite. You have to come by path of discovery honestly.
A small number of metaphors consistently (re)applied throughout the system. Every time a new metaphor is added to a system, the impact of its existing metaphors are diluted. A counter-example of this in a class library is using getCount in one class, count in another, and then size in yet another. However, each has the same basic semantic. Doing this makes the user distrust you. Why? Because you keep making them learn new things that do not build on what they have already learned. Worse yet, the same things work differently in different parts of the system. The only way to make a complex system simple is to find its primary metaphors, focus on them, and to religiously protect them from new metaphors that will reduce their impact. This goes for anything, if the user learns something about the system, reward them by allowing them to build on that knowledge.
The user identifies with the system. This is hard to quantify. Somehow, the user feels unique for choosing/using this system. There is something special about using this as opposed to other solutions in the same problem space. Sometimes another system may even be more complete or perform better, but something about the other system makes the user identify with it. The user doesn't exactly feel elite but elitism is close. As the user evolves in their understanding of the system, they begin to emotionally identify with the system more and more. Kind of like how some people identify with wearing black or how a little ear-ring makes them feel unique. For some reason, this usually requires some small dose of subversiveness in either the underlying technology or the aesthetic of the system. Think of the Macintosh Superbowl Commercial -- that was subversive. On the other hand, Big Blue isn't a subversive image. People want to feel that there is something different or subversive about what they use. Both SmallTalk and the Mac had elements of being different and both were very subversive.

These are the big three. Because of these, because (a) there is a path of discovery, because (b) the complexity is elegantly simplified by a few key concepts consistently applied, and (c) because the user can identify with the system....because of all of these, you cause the user to change. And herein lies (d), or the composite of these three attributes....the user is changed. They can do things they never did before. This could be programming for a programmer, entering accounts quickly for a data entry operator, or listening to a musical artist that finally enables you hear jazz. This composite is what is needed to create a ParadigmShift. I've thought about it a lot, and for me. These are the big three of creating anything great. Think about music, most great music is also a path of discovery. You hear more each time you listen to it. Anyway. -- RobertDiFalco

Discussion:

Robert, I appreciate this page and the many important issues you've raised here, on ChiefArchitect and elsewhere. Clearly "architect" is a label that carries many important concepts with it, for you, and I have no problem with that. GreatDesign is vital to encourage (and indeed not mess up by shallow consensus) and for me you've captured some really important facets of it, which is not easy to do. Don't be sidetracked by those for whom the term brings mostly negative connotations, indeed those of us who have often wanted to remove it from commercial situations in favour of the more humdrum "designer", as this has often been in order to achieve many of the same goals.

As I see it, you're using a broader brush than Wiki is used to. Citing AlanKay as architect of Smalltalk, Ward as architect of Wiki and Kent as architect of XP you're saying that the word can be used, with some commonality of meaning, for the design of the radical new language and environment that more or less defined ObjectOriented from the 1970s, a radical new medium for collaborative writing over the Internet from the early 1990s and a radical new software development method that cleverly piggy backed on the both of them. "Architect of XP" is the weakest for me. There are other ways to be nice about Kent and Wiki has tried many of them! I think especially of AlistairCockburn's "master of culture and cultural change" towards the end of EveryoneShouldBeaMethodologist. I agree with your call for more tolerance of diversity under the broad umbrella of XP, as seen through Wiki, and again this calls into question for me the wisdom of Kent being called "architect".

But that feels like quibbling, something for later WikiPages that hang off here in years to come. For now, thanks for bringing a "breath of fresh air" to Wiki's discussion of design or perhaps a much needed "kick in the pants". (And with TeenageSlang plus many signs of Wiki adults being "divided by a common language", that idiom is no doubt going to cause further "terminological inexactitude", as WinstonChurchill might say.) -- RichardDrake

Do you say this because you don't view processes or methodologies as having an architecture or because you do not think XP is representative of KentBeck's best work. Besides books on patterns, presentations and such I'm not familiar with any other full-blown systems he's worked on. The following lists the reason that I believe the process is a successful architecture and an excellent example of GreatDesign even though I disagree with much of its details:

XP evolved beyond the architects initial vision.
XP captured the imagination and devotion of many people. This is closely related to the next bullet.
XP practitioners feel unique for using it.
XP has very few rules each with a deep semantic and each consistently applied through out the system.
XP will continue long after the architect(s) move on.

To me, these are key indicators. I cite XP only to show that (a) architecture does not only apply to software systems and (b) that my disagreeing with it does not detract from its success as a system, and (c) an example of GoodDesign usually has detractors that are as passionate as its enthusiasts. While the actual applicability of XP is another topic altogether and not yet clear, what is clear is that XP has hit on many key issues that will influence and evolve software development.

-- RobertDiFalco

Interesting points. I'm not quite as convinced as you are on XP having all of these properties. I'd say XP is a GreatEffort?, not so much a GreatDesign and even less a GreatArchitect?(ure). On the other hand, I believe it has a great chance of changing the way almost all software is written is a few years hence. In this it benefits from the past customer relationship successes of EvolutionaryDelivery, as documented by TomGilb, and other incremental pioneers. Part of what Kent and Ron got right was timing. Was that "architected" or was it luck? It is a hallmark of the great software designer, whatever. As Napoleon once said on being told of the great qualities of a general being proposed for some new venture: "But is he lucky?". -- RichardDrake

Maybe the fourth bullet is a little gracious. However, I think it is important that you note there is very little that is new in XP. I agree, almost all is taken from proven practices that have been popular in the O-O world and beyond for some time --- specifically evolutionary prototyping and incremental development. However, Xp is unique in putting these together in a way that was almost religious for people new to these BestPractice's and techniques. This coupled with light-weight and high-discipline hit on something essential for many people -- clearly or there wouldn't be this buzz. As Stravinsky was fond of saying Lesser artists borrow, great artists steal. I think you can still create an important Process Architecture or Software Architecture without a single original concept -- I'm not saying there aren't new concepts in Xp, I just don't know what they are. Sometimes the beauty is in the composition of the ideas rather than the ideas themself. I don't think something has to be complex to be an architecture, but I don't imagine you do either. I also think it's possible to hit on something great by accident. This doesn't mean that Xp won't turn out to be the COBOL of development processes. In many ways I think it already is. I'm just trying to look beyond my aesthetics and recognize a phenomena. -- rad

I think this quote from PaulGraham is also relevant: "Great software, likewise, requires a fanatical devotion to beauty. If you look inside good software, you find that parts no one is ever supposed to see are beautiful too" Great designs/software has a fanatical attention to detail(s which may be barely perceptible) which subtly enhances the whole. (See BeautyIsOurBusiness)

Elsewhere on Wiki, I saw a discussion about objects definable as a tuple of attributes: name, extensional meanings (examples), and intensional meanings (specifications) - I've mangled the terms, lost the WikiPage, but believe I've captured the idea. The point is that GoodDesign or ExcellentDesign? would seem to be an effective (accurate, efficient, elegant etc. - pick your adjective and have at it) conformity of all three attributes across a wide spectrum of people interacting with the design. GreatDesign, if I have the Zen of it correctly, not only fulfills that, but goes beyond by opening new possible spaces and concepts - ones that that the designer did not understand, or anticipate as an element of the design. If there is not a WikiPage for DesignAsAdaptiveBehavior?, there ought to be. -- DanEsch (I am beginning to feel like a kid in an intellectual candy store and if I am violating WikiNorms? with my posts (I hope not!), do please drop a line on my page and let me know. Feel free to leave a paper bag for head-covering purposes.)

CategoryPlanning