Kathy Sierra, on her excellent blog (which may have very sadly come to a close now, but that’s another long and sad story) has recently published a collection of her favourite graphics from the last few years.

Here is one that I really like:

(By Kathy Sierra, from http://headrush.typepad.com/,
shamelessly copied without permission – I hope she doesn’t mind!)

You should really look at the site yourself – there are many more great diagrams!

The Featuritis diagram above struck a nerve with me, since it’s something that’s been close to my heart for a long time. It is also related to what I think is one of the Natural Laws Of Software Development:

Every open system develops towards the unusable.

If you want to find out why I think that, read on.

The first part of this is the observation illustrated in Kathy’s diagram above: that the simple rule “more features is better” is just poppycock.

(Aside: a sad part of this is that even people who agree here in principle get sucked in to this regularly. Marketing people, of course, love features. Marketing people need arguments to sell stuff, and features give them their foot holds to stand on. Many people who buy products – professionally or privately – follow the tick list approach: if product X does all that product Y does, plus more, it must obviously be better.

Developers know about tick list purchasing too, and so they go into tick list development: Our product must do all that our competitor’s does, plus one more thing.

Even if you know about this, it’s sometimes hard to resist. Imagine you want to buy a digital camera, and you stand in the store and stare at the 27 different models a bit like a mildly senile sheep would stare at a small type printout of the theory of relativity, it is very tempting to go by whoever promises to do most. Unfortunately, very few design for, and then advertise with, good usability, and those who do are mostly lying.

There is hope, though: look at the iPod, for example. It always had less functionality than competitors, with a benefit for usability, and people have actually noticed, and they are buying these things like crazy. So not all is lost.

But most companies are just not brave enough to design for simplicity. I’ll come back to bravery below.)

So, let’s assume we agree that more features is not better to an unlimited degree, and that the “Happy User Peak” indeed does exist. (And if we don’t agree, then you’re wrong: It does, I tell you!)

The second aspect is specifically relevant to open source systems (and other open systems, by which I mean those that are ultimately influenced by a large group of people, either through direct participation or through community processes, or similar.) For simplicity’s sake, I’ll call them “open source” systems for the rest of today.

For open source systems, another factor comes in: reward.

We all do things to get rewarded. Being rewarded is being made to feel good somehow, to receive something that you like to get. The kind of rewards can be very different, but we all need rewards. (To think that open source programmers spend all their time and effort without reward would be naïve, and against human psychology.)

The rewards of open source programmers differ, of course, from those of commercial programmers. For professional programmers, the reward is (at least partly) money.

So what is the reward for open source programmers? Well, typically it is peer recognition, and the satisfaction you get from seeing someone else use your work. We all like to get the occasional mails back saying “cool stuff what you did there – I really love your work”. Or something of that kind.

Just being known for having contributed something useful to the community is sufficient reward for quite a few. Peer recognition. Pure and simple.

Now, the problem with this in this context is that there is very little peer recognition to be earned in geek communities for not doing something. Or for removing a feature.

As a result, typically the only way to enter into and be recognised in an open source community, it to add something. And that means that the amount of features in an open system will continuously increase over time:

Number of features over time in an open system

Since rewards in collaborative communities are for individual bits of work, and simplicity is an overall system property, collaborative systems have a hard time rewarding simplicity.

Now, if you take this together with the Happy User Peak, you get my Natural Law from above:

Every open system develops towards the unusable.

Another part of the problem is that, even if some people can easily agree that we should fight feature creep and concentrate on the core features, they can never agree on what the core features are.

Too many people have their own favourite feature, that they see as absolutely essential for their daily work, and they will insist on it going in. And simplicity goes out the window quicker than a rat up a drainpipe.

So, what we really need is for a system developing towards the Happy User Peak, and then somebody pulling the hand brake and saying – “That’s it, folks, from now on we are only maintaining compatibility, keep the system running, oiling the cogs, but no new features. Anyone who adds a feature will be shot.”

In practice, this rarely happens. Why is that?

One problem is that it is very hard to agree where the peak is. When is the right time to stop. If your system is actually successful (meaning a good number of people find it useful enough that they actually use it), then there will always be a few hundred people pushing for something extra.

(And make no mistake: feature count is a one way street. It will only go up. The only way to get a system with fewer features is to write a new application.)

So typically a group of people discuss this, several people push the feature count (upwards, of course), the system slowly grows, we cannot agree when we have reached the peak, and one morning we all wake up and realise that we have long passed it.

We have seen it many times. Microsoft Word. Where the last few versions have been mainly about trying out new techniques for coping with an unmanageable amount of features. (How about removing some features? No? Well, I didn’t think so.)

Eclipse is also heading this way. And Java. Java started out as a small, clean, neatly designed language that really had a feel of the clarity of a single person’s design. It was far from perfect, but it clearly valued simplicity over completeness of features. And now look at the later additions. Genericity. The design of genericity in Java has special syntax for some rather esoteric cases – it really smells like design by committee. Like something where everyone had to get their favourite use case explicitly supported. And the result: while I knew a good number of people before, who could explain any and every valid Java statement, I can now write valid Java code that almost nobody on the planet can correctly explain. Josh Bloch and Neal Gafter excepted, maybe.

Even the iPod! Video? I don’t need no stinkin’ video on my MP3 player!

Above I said it takes a brave person to build a simple system. That is because people always worry that simplicity is mistaken for triviality. And rightly so: many people are impressed by anything they cannot understand (“oh, what clever people it must have been who built this”), and don’t appreciate the difficulty to engineer simplicity.

If your boss is one of those persons, then you’re in trouble. Michael Jackson – no not the singer! – has a great story about this. One of my favourite quotes:

from: Michael Jackson: “Software Specifications and Requirements: a lexicon of practice, principles
and prejudices”, Addison-Wesley, 1995. ISBN 0-201-87712-0 (Amazon)

So what is the way out of this? Is there any hope? I know of only one way how this can be stopped (or at least slowed): a system needs a dictator. No committee, no group decisions. Have discussions, by all means. Talk, gather ideas.

But then one person has to make the decision. And that has to be someone who has a single plan in mind, and who is not afraid to offend people by rejecting their (individually good) ideas.

Open communities are great for development. They are a disaster for design.