Thinksum

The golden mean of product design

James Surowiecki, author of The Wisdom of Crowds, has a fine little essay on product design in the May issue of the New Yorker.

I think the morale is that people don’t always know what they want, but they know what they like when they get it.  This is why great products are “designed,” not just developed.

The Goldilocks Principle

This just came up for us for the second time in as many releases.  Here's the problem:  there's a capability you want to add to a system, let's call it a new knob.  Imagine a stereo that just has Volume control, but now you want to add Bass and Treble control too.  The knob is meant to give people a choice on what level they prefer or want to assign (for example, the knob might be used to assign a level to each individual object in some system).

But the question (aside from all the other little details) is:  how many levels does a person need or want to choose from?

Since this has come up for us in each of our last two releases, I've had the experience of querying a bunch of people for their opinions.  What I've learned is that each person just likes their levels a specific way.  Some people just like two ... they'd always be happy with just High and Low.  Some people just always like ten ... ten for them is a kind of magic number that gives almost complete control without overly confusing granularity.  And some people think that every person should be able to set their own scale, even name each setting on the scale, so then everyone can be happy (except for the developers, QA and support folks who have to deal with implementing, testing and supporting this forevermore).

Me, I like three levels.  I call it the Goldilocks Principle for levels.  The first bowl was too hot, the second one was too cold, but the third one was just right.

If you only give a person two choices -- such as High and Low, or High and Normal -- they may not feel they have enough control or ability to differentiate.  But if you give them three choices -- corresponding to some sort of High, Medium and Low -- it usually works out "just right."  For me, three provides the balance between lack-of-differentiation and over-complexity.  For most software, it's not usually necessary to have 10 levels or completely configurable levels on the little knobs that are added to objects in a system.  Plus three is a number that's easy to implement, easy to test, and easy for everyone to explain and understand (so no support issues).

So, like any good software designer, I listened to everyone's opinion but then I picked the design I liked the most.  No one's complaining too loudly so far.

Future-proofing

Like most areas of software, the identity and security space is filled with an ever-increasing set of standards and proposed standards.  In recent years we've got NAC, NAP, SAML, WSS, OPSEC, SPML, XACML not to mention many others to consider.

So when you're working on the next version of your software, which standards should you support?

Personally, I believe in future-proofing the code, not the features.

Here's what I mean.  In most cases it's impossible or risky at best to predict the future.  Just because a standard is a good idea, or even if it's pushed by a big vendor, doesn't mean customers will support it.  Customers have to deal with legacy systems and they want to avoid vendor lock-in.

Most importantly, when customers are going to adopt a standard and they want you to support it, they'll let you know.  Then it's not the future anymore -- then it's NOW.  Of course if there's a perfectly good standard that's widely recognized and it makes sense to use it within your product as opposed to designing your own proprietary standard, again that means it makes sense NOW.

For standards that are not critical NOW, rather than future-proof your product it's more important to make sure that your code is designed in a future-proof way so you are not prevented from moving to new standards in the future.  The details of future-proofing the code will be different for every product, but it usually means modular design, loosely-coupled components, portable coding standards and the reliance on machine-readable messaging between software components.

Some people will worry, however, that if you wait until the customer wants it, it will be too late.  A competitor will already support some emerging standard, and you'll never catch up.  Personally, I've never seen this actually be the case and I can't think of a single example in the history of software when this was true.  Customers always give plenty of notice, and there's always time to catch up if you do a good job.  The problem is that many companies don't listen to their customers and they try to force their own agenda -- if you do this, then of course your product may go the way of the dinosaurs.

Here's an example:  when I worked at Lotus, the Lotus 1-2-3 spreadsheet was the most widely used software application in the world.  But the PC operating system environment was evolving, and camps formed to predict what the future would bring.  Some predicted Microsoft would continue to dominate, but some predicted that IBM OS/2 was the future.  Lotus put all its eggs in the OS/2 basket.  There were two key mistakes in this:  1) betting on OS/2 too early before there was clear widespread customer demand;  2) trying to force a corporate agenda (fight Microsoft at all costs) even when it became clear that customers were going to choose Microsoft Windows over OS/2.  It wasn't that Lotus failed to anticipate the future and therefore lost the game, but rather that Lotus tried to fight what customers wanted when it was clear.  I've read many different analyses of this failure, but having been inside I can tell you that Lotus fought the tide even when the inevitable was clear, and this is the major reason that Lotus 1-2-3 is dead.

So design your code for flexibility in the future, but build features and adopt standards that are important to your customers now.  Don't worry about predicting the future, just worry about who your customers are and listen to what they tell you.

Software Snobs

I just finished reading Bob Dylan's autobiographical Chronicles: Volume One.  If you're a real Dylan fan then it's a must read, shedding light on his artistic process and how he sees the world.  If you're not a Dylan fan, I have no way to know whether it would be appealing or not (I'd guess not, because if you don't like his songs you probably won't like his writing style).

One thing that we know about Dylan and that the book makes ever-apparent is that he is an original.  Following in the footsteps of a few (namely Woody Guthrie), influenced by many (blues, folk, rock), still and foremost he is remarkable for finding and defining his own musical language.  And though many tried to box him in or turn him into what they wanted him to be, he resisted and fought their attempts to file him away under a nice, simple label ("folk musician," "protest song-writer," "60s icon," etc.).

At one point in the book, Dylan mentions how one folk music critic kept telling him that everything he was doing had been done before by others and better.  Dylan called the critic a "snob," and noted that the music world was filled with snobs on all sides -- the folk music snobs, the rock snobs, the club scene snobs, etc.  Dylan sensed intuitively that, to be what he wanted to be, he had to avoid and ignore the snobs.

The dictionary defines snob as: 

1. One who tends to patronize, rebuff, or ignore people regarded as social inferiors and imitate, admire, or seek association with people regarded as social superiors.
2. One who affects an offensive air of self-satisfied superiority in matters of taste or intellect.

it's probably true that in every walk of life there are snobs.  Art snobs, music snobs, political snobs, religious snobs, regional snobs, on and on.  Certainly in software and technology we are not immune, in fact we are often a flaming case in point.  Linux snobs, Microsoft snobs, Apple snobs, Java snobs, Lisp snobs, C++ snobs, academic snobs, etc. etc.  You can like and use and even espouse a technology without being a snob, but it's that "air of self-satisfied superiority" that often tips the scales.  Then there are the "insider" snobs, those who "ignore people regarded as social inferiors and imitate, admire, or seek association with" the "hot" VCs, entrepeneurs, companies (Google Google Google).

And if you give a snob a blog (blogging snobs? snob bloggers?) watch out.

The mistake is in paying too much attention to the snobs (let's put aside being a snob, which is obviously a short-sighted mistake in itself).  It's not that snobs are always wrong, but they're dangerous because when they are wrong they are still fully convinced (and in some ways convincing) that they're right.  Whether it's managing your career or your product, my experience is that you need to find the honest voices inside and outside to help guide you, and you're usually better off avoiding the self-proclaimed experts.  If you spend your time trying to please the snobs, you will waste the time and energy you needed to find your own successful path.  This doesn't mean you should turn down a helping hand or not listen to experienced advice, but simply recognize that any "expert" worth their salt will never tell you that they know everything about how to run your product, your business, your life.

Here are a couple of signals I look for to detect snobs:

1. Disdain for questions.  If someone offers an opinion, and I ask "why do you think that?" I expect they'll be happy to answer it.  If they are put out by the question, don't welcome the discussion, or answer in a patronizing tone, then my snob-alert goes off.  (remind you of any politicians?)

2. Anger upon challenge.   If someone offers an opinion, and I challenge it (without being nasty) I expect to hear a solid defense.  If the response to my challenge is filled with anger or bullying, even subtle, then again I suspect I'm dealing with a snob.

Again, snobs are not always wrong, but as trusted advisors or co-workers, they can be a real pain and more dangerous than they're worth.  Thank god Dylan didn't listen to the snobs, or we wouldn't have 40 years of remarkable music from 1964/65 Bringing It All Back Home and Highway 61 Revisited to more recent works like Time Out of Mind including Tryin' to Get to Heaven ... no one else in music writes lyrics quite like this:

I'm going down the river
Down to New Orleans
They tell me everything is going to be all right
But I don't know what "all right" even means
I was riding in a buggy with Miss Mary-Jane
Miss Mary-Jane has a house in Baltimore
I've been all around the world, boys
Now I'm trying to get to heaven before they close the door

It Matters Who You Ask

Dare Obasanjo had an interesting post a few weeks ago that included a link to an old Slashdot article discussing a preview of the iPod, where the reviewer called the iPod "lame."

We all know now that the iPod is not categorically "lame."  But I wonder if the product designers read the post at the time (got to believe they did) and what they thought about it.  This made me think about one of the classic dilemmas in all product design and enhancement:  which feedback should you listen to, and which should you ignore?

I found a great analogy in a book I just finished reading by William Gibson called Idoru.  I'm an avowed Gibson fan -- he's the author of the breakthrough cyberpunk novel Neuromancer, he's credited with the inventing the term "cyberspace," he's the godfather of the Matrix and many other movies. 

Idoru is the story of a mega rock star who wants to marry a synthetic software celebrity (the idoru).  One of the main characters is Colin Laney, who due to drug experimentation in the past has developed a neural, almost psychic skill to tap into large streams of data and quickly sense the most telling bits.  He says he can find the "nodal points" in the data.  The American Heritage dictionary defines nodal as "of, relating to, resembling, being, or situated near or at a node."   In other words, Laney was able to find the meaningful clusters within the data, and to derive understanding from those clusters.

That's essentially what a product designer needs to do.  One way or another, if the product is made available to other humans, you will get feedback, invited or not.  This feedback is data whether it's recorded formally (in a spreadsheet for instance) or just informally (in your memory).  The gifted designer must learn to intuitively sense, identify and act upon the meaningful clusters, or "nodal points," from that feedback so they can improve the product design.

But there's one huge caveat:  it matters who you ask.   If the iPod designers had asked the Slashdot author to help them improve the iPod design, that probably would have been a huge mistake (at least for the financial success of the iPod).  And if the designers had asked a hundred or thousand people like that Slashdot author for their opinion, there would have been clusters of data around some possibly bad ideas.

So whether dealing with customers or just people off the street, it's important to remember that not everyone's opinion should be treated equally.  The product designer needs to find the nodal points that actually connect to where they want to take the product, to the audience they want to reach.  This doesn't mean that we should only seek feedback from people who match our target customer profile, but instead it means that the designer must be able to decide which feedback will be relevant for target customers.  If you're not sure, incorporate the feedback in a prototype and then test that with some target customers.  But it's not a science, it's an art, and like Laney the best designers have an innate sense of where they want to take a product and who to ask for feedback to help them get there.

Year 2K5

After Year 2K you would think that everyone who had a timebomb in their program would make every effort to get it out and let the world know.  Last week at Epiphany, and also at other companies like Cisco and BEA, folks had to scramble because on July 13th Sun notified the world that a widely used Java library had a component that would become non-functional two weeks later, on July 27th.  The Java Cryptography Extension (JCE) package is used by many J2EE applications to encrypt passwords or other sensitive data (and as of version 1.4 it is actually formally part of J2EE).  This error meant that after July 27th, older applications not recently upgraded would fail.

I'm not trying to bash Sun here.  The version with the timebomb had been replaced by a newer version which eliminated the timebomb problem a few years back.  But clearly, we at Epiphany (where we work hard to monitor these things) and others like Cisco and BEA were somewhat blindsided by this, since we all had to release emergency upgrade patches and notices to customers in the last week.  Luckily, at least at Epiphany, we seem to have effectively addressed the issue at customer sites.

The morale of the story is this:  any software that you write should not have any timebombs, period (free trial versions of software aside).   If the software is widely distributed (and when you're building it that's usually your hope) it will probably be in use much longer than you think.  If you do have a timebomb in some software you've written and distributed, you owe it to your users to do much more than normal to alert them as early as possible.

Simplicity Rules

I'm working on a few different software design projects.  At Epiphany, we're designing a new generation of products.  As a personal project I'm designing a new web service for friends to share and discover things they like.

So recently I got to thinking about the rules I use for design decisions.  I realized there's one rule that I use frequently that might be worth sharing.

Let's call it the Simplicity Rule, and it could be phrased like this:  what you leave out is as important as what you put in.

If you've designed software, you're familiar with the term "feature creep."  It's the easiest thing to do and one of the hardest to stop.  When you're discussing or thinking about possible features you might find yourself saying or thinking something like "wow, that would be cool" or "it could do this too."   If you ask 10 people what features you could add you'll get a 100 ideas, and if you ask a 100 you'll get a 1000.

The hardest thing I find is not trying to come up with ideas of what to put in -- there are plenty of ideas for that -- but deciding what to leave out.  To do it, I have to constantly ask myself:  what is the real purpose of this software, and is the feature core to that purpose or not?

There are two key problems with feature creep:  it can cause the length of a project to continue on and on; and it can cause the real value of the software to be diluted or even drowned in a sea of less important features, to the point that the people using the software can no longer clearly understand or appreciate the core value.  In my mind, the best software is like the best cooking, with just enough of the right amount of everything, and not too much.  I'd rather err on the side of simplicity.  I can always add a little salt at the table, but if I add in too much salt while cooking then the dish is ruined for everyone.

The best software books I know that espouse the power of simplicity are the classic Software Tools by Brian Kernighan and P.J. Plauger, and The Practice of Programming by Kernighan and Rob Pike.  While C may have its detractors (hello Lisp lovers) its huge popularity derived from its wonderful simplicity, and these books come from a group at Bell Labs that appreciated the power of simple and direct design.

Another influence on my design thinking are the philosophical works I read in my 20s, such as Thoreau's timeless ode to simplicity, Walden.  And The Way of Life, in which Lao Tzu defines a deep and rich world view in 81 poems without hardly a wasted word.  And Zen Buddhist thought and art, my favorite example of which is Kakuan's 10 Bulls (the influence for Cat Stevens' Catch Bull at Four if you didn't know).  While I'm not a Buddhist, I deeply appreciate the precision and profound simplicity that characterizes the best of Eastern thought.  The great Buddhist Monks appreciated the fact that silence can be more powerful than words.

Finally, I think Einstein's E=MC² is probably under-appreciated for its overall influence on our lives and how we think.  I know the idea that such a simple scientific expression can have such far-reaching implications has influenced how I think about software.

And then, of course, there's the Google home page.