Joel on Software: Choices = Headaches
THANK you. Joel succinctly and illustratively makes a point with which I agree wholeheartedly: too many choices are a bad thing.
Around the workplace, I’m an outspoken advocate of individual choice — particularly with respect to things like our physical work environment, the hours we work (i.e. flex time), and our individual hardware and software tools. That’s because, historically, we’ve had little or no choice. Some choice is better than no choice. Things are better, and improving all the time, step by step. But we still exist somewhere near the conservative extreme of the spectrum, and so I still feel compelled to advocate choice.
On the opposite extreme of the spectrum is the kind of thing Joel is talking about. Maybe software design and office management are apples and oranges to you, but ultimately their aim is asking the same question, “what is your preference?”
To augment Joel’s point, think of it like this: each of us is actually a manager of at least one employee: a computer. We make requests of our computers and ask them to perform duties: show me my email, let me write some code, send this file to Bob.
A computer program that offers too much choice is like an employee who can’t think for himself, who requires micromanagement and babysitting.
Imagine if my supervisor came by and asked me to write an Issue Paper for the board. What if I answered his request with a list of questions of my own?
- What should the subject matter of the paper be?
- How many paragraphs should the paper contain?
- How many footnotes?
- Should I use MLA-style reference citations?
- Should I include an executive summary?
- If I use the word “color,” would you prefer I used the British spelling (“colour”)?
- Should I use straight quotation marks or curly ones?
At least the first question started to touch on discussion that was relevant given the context. Even though I would deserve to be laughed at after my barrage of irrelevancy, Chris would probably be nice and give me some direction that would lead to greater self-sufficiency in me. Either that, or he would acquiesce and exhaustively answer all of my questions, and when the paper is done he would realize that having me there to help him really didn’t save him much time or effort. He would realize that I really hadn’t put any thought into helping him make a smart choice — I had only catalogued an exhaustive list of every choice, relevant or not, smart or not.
That’s what it feels like to use software that offers too many choices. That’s what it feels like whenever I’m trying to get something done in Windows or KDE, or when I want to make an Infragistics control just do something simple (they can do powerful things, but they can’t do anything simply).
What’s the alternative? An employee who takes some initiative, who does some of the smart thinking, independently. Software that takes some initiative, that does some of the smart thinking, independently.
I don’t need a hundred choices as long as I’m given the smartest three that make sense given what I’m trying to do. Think the computer can’t possibly be so helpful? Of course it can! If Joel’s example wasn’t enough, I’d be glad to show you how Windows’ numerous and partially-but-not-entirely redundant configuration panels for my wife’s WiFi card could be consolidated into a single panel.
If this is starting to sound too negative, then here’s the positive: let’s take some initiative and do some of the smart thinking every time we design a piece of software. Let’s shoot for making software products that are as valuable as independently thinking employees. And let’s advocate greater choice and diversity in the workplace, too, so programmers whose cup of tea is not micromanaging and babysitting the computers they employ can unleash even greater productivity.
[Insert video clip of the British parliament pounding their desks and shouting "Hear, hear!"]
