This originally appeared on the Joel on Software discussion group. This issue was the value of simplicity in product design, and whether it requires removing features.
There is a difference between features of the product and features exposed in the user interface. Take automobile traction control as an example. If you don’t know, it uses sensors in each wheel to detect a slipping wheel and either apply the brakes or limit power to that wheel until it stops slipping. Many cars have this feature now, but most don’t have any user interface to it.
Some cars, though, have a button you can press when you’re driving in icy conditions. This changes the response of the system to be more aggressive about stopping wheelspin.
Then there’s the Corvette. The first version to have traction control had the option to completely disable it. Under racetrack conditions, sometimes the fastest line requires intentionally sliding the rear end to set up for the next turn. Traction control can’t anticipate that.
In the real world, how many people are actually good enough drivers that they can take advantage of that exceptional condition? How often are they really able to take advantage of it? How many ever have?
Now how many people want to believe that someday they’ll drive like that? The feature makes the car better. Needlessly exposing the feature in the user interface makes the car more marketable. People like to believe they’re not average, but instead the elite for whom “good enough” just isn’t.
A related phenomenon leads to Jeep commercials touting the off-road prowess of vehicles that, for the most part, never leave the suburbs. People want to believe that they someday will do something exceptional, and want their product to support that belief.
Nissan, back when they were called Datsun, once had a commercial that came right out and said it: “You won’t go 0-50 in 6 seconds flat but you know you could. You won’t use it’s drag speed of over 100 mp/h but you know you could. And when the light turns green you won’t flaunt your turbo power but knowing you could is awesome!”
Now apply this to the washing machine that senses what kind of load it has. Personally, I can’t think of many things I care less about than my skill in classifying loads of laundry. But I would still have trouble accepting a salesman’s pitch that really, the machine is smarter than me about this. If Consumer Reports backed it up, though, I’d take a one-button washer and a one-button dryer.
Now consider the first iPod. It didn’t play several poplar audio file formats. Lack of this capability is not “simplicity”. If the codecs were added, the user interface wouldn’t have to change. More features, same simplicity.
Then there are cars with remote keyless entry that doesn’t depend on pressing a button. Simply approach the car with the fob in your pocket and the doors unlock. Very simple. But there are times you need to decide whether the car is locked or not
If you have your spare keys in your gym bag in the trunk when you walk away, the car doesn’t lock. Oops.
You can’t leave the car unlocked while you and the kids make several trips to unload groceries. You’d have to hand off the remote every time one of you goes down.
I think the process probably could be simplified, but I would want extensive usability testing and design work before I would take a car that decided for me when to be locked and when to be unlocked.
Finally, consider two different cars.
Three-speed stick shift
Solid rear axle
Adaptive all-wheel drive
Which one is simpler? Hmm, that depends. Do you mean simpler in design, or simpler for the user?
Let’s make it closer, and say Vehicle #1 is now an automatic. Now they’re equally simple for the user. But Vehicle #2 does more, making the decisions for the user.
In “Choices = Headaches” Joel said the user interface should be simple. Not that the features shouldn’t be there, just that the user shouldn’t have to chose when to use which.
Dave Winer has done more laps around the programming track than most of us. He’s seen the same code recreated again and again on each new platform, as the next generation of developers thinks they can start from a clean sheet of paper and not make the same mistakes as everyone else.
I won’t say they’re completely wrong … they manage to add some new mistakes every time.
It’s not just the code; they keep reinventing the same business models, too. For example: Create an open platform, get independent developers to target your platform, then shut off the API once you’ve reached critical mass.
Older guys see this play coming a mile away, but younger guys always seem to think this time is different, no matter how many times you warn them. But you have to keep warning them anyway, don’t you?
I think so, and I thought Dave did, too. That’s why I was so surprised by his response to a comment I left on his blog.
I like the idea of Twitter going back to its roots with developers. It plays to its strength as a platform. The challenge here is due to how many have been burned. On the flip side, there aren’t a lot of obvious alternatives.
The cynic in me says that’s not a challenge at all. There’s always a fresh pool of developers who haven’t been burned yet. And they never listen to the “old guys” who have seen it happen again and again.
Everyone has heard that opinion, it’s what gets said over and over. Try to add new ideas.
Which honestly confuses me. Yes, it gets said over and over. Because it’s true over and over. And companies will keep pulling the same shit with developers as long as it keeps being true.
Dave has tried dropping out, ignoring the latest re-hash of the same stuff he was writing in the 80s. He even deleted his Facebook account and avoided the platform for more than two years. Eventually he started working with them because, “Facebook delivers more readers and engagement. And despite all the advantages of blogging, Facebook is winning.”
Makes sense. If you want people to hear what you’re saying you have to go where they’re listening. And if you’ve been around the block a few times you go in with your eyes open.
But when someone suggests that a company can’t do something because of how they’ve burned developers in the past, don’t those of us who have seen it have an obligation to stand up again and tell the story?
Whether a falsehood is stated through ignorance or malice, if no one disagrees it becomes the conventional wisdom.
dim for as integer
dim loop as integer = 10
dim next as integer = 12
for for = 1 to loop
if for > loop then
for next = loop to for
for = next + loop
If you’ve been online long enough to have found this article you’ve probably seen, or even participated in, a flamewar. Seen from the outside, you know you’re looking at two people exactly like this guy:
You don’t normally see flamewars in real life except in special-interest forums: politics, academia, sports,cosmology.
Then there are those special people, the polyflamers who will argue on any topic. No, not lawyers. Geeks.
Something in the geek psyche makes them — okay, us — prone to obsess over pedantic distinctions that ordinary people just don’t care about. If you think about flaming in geek terms, though, you see a way out.
When writing code, a programmer usually writes instructions that are in (somewhat) human-readable form. These instructions are then “compiled” into commands that a computer can interpret and execute. If the output from the computer is wrong, either the commands the programmer entered were wrong, or the compiler didn’t work correctly.
Experienced programmers quickly learn that it’s very unlikely they’ve found a new compiler bug. If there’s a problem, it’s almost always the code they wrote. Sometimes, though, there really is a bug in the compiler. Compilers can get fixed, but not quickly, and not often. The changes have to be small enough that they don’t introduce new problems. And they will potentially break any code that was designed to work around the bugs. Which is exactly what programmers do: They work around the bugs.
Now think about a political campaign as a computer program. The campaign staff is writing instructions (commercials) that they hope will cause the public to exhibit specific behavior. But the target platform is the brain of each individual voter. Each one has its own rules, so every compiler works differently. But here’s the important part: You can’t fix the compiler. No matter how broken you think someone’s thinking is you can’t change the basic rules.
What you can do is figure out what rules they’re using. Which means stereotyping people. pigeonholing them based on a few characteristics you’re sure of, and assuming that a whole bunch of other things are probably also true. The sad fact about humanity — sad if you’re a fan of individuality, that is — is that this tends to work pretty well.
These are not the earmarks you were looking for
So now that you know each brain is wired differently, and you don’t have much chance to “fix” it, what are you supposed to do about it? Stop using arguments that work on you, and start using ones that work on them. Whoever “them” happens to be at the moment.
 Combine two and you get the observation that academic politics are so vicious precisely because the stakes are so small. Attributed to Woodrow Wilson after his time as president of Princeton University.