Embracing bias in software design

I feel like I'm posting a lot about 37 Signals lately, but Jason kicked up a minor (but highly interesting) controversy yesterday.

He posted about one of the common Basecamp feature requests that they have chosen not to implement, and tried to explain why. (Be sure to scroll down and read Jason's comment as well as the original post.)

Jason argues that despite many requests to the contrary, one should not be able to assign a task in Basecamp to multiple people because, "The more people you make responsible for something, the less chance there is for it to get done." Commenters immediately snapped back, calling 37 Signals arrogant, naive, unresponsive and foolish. "How dare you tell us how we should work!" they cried.

First of all, I strongly agree with Jason. We used to follow the multiple-asignee practice at my day job, but my team decided not to allow it, much to our benefit. (That was one of the compelling reasons that we decided to get a new, better bug-tracker — one that worked the way we wanted to work, and that agreed with our ideas about software development practices.)

And today, David from 37 Signals backed Jason up with some really insightful comments.

Neither Basecamp nor Rails is trying to be all things to all people. Because you can't. And once you realize that, it becomes a lot easier to embed opinions in your software. They're going to be there anyway. Kind of like the notion of "objective journalism", the bias can never be rooted out.

I firmly agree with DHH here: bias is inevitable in software (and in most things). I've heard plenty of sales pitches where the presenter promises that his tool will, "adapt to work the way you do." Unfortunately, I don't believe that for a second. All software is built with the assumptions and biases of it's designers. They either did a good job with those decisions or they didn't. And you, as a user, are left to either work with the tool, or work against it.

When we were demoing workflow tools last year I had the opportunity to play with the Rational Suite and CA’s software development tools. Though their marketing sometimes says otherwise, Rational strongly encodes their assumptions about the development process into their products. CA, on the other hand, argues that their tool will adapt to your existing business processes — it is almost infinitely configurable. And while I wouldn’t want to use either of them, I recognize that Rational is, by far, the better-designed product. I wouldn’t buy Rational’s tools because I don’t agree with their biases. But I wouldn’t buy CA tools because they are a confusing, bloated, poorly-designed mess.

The pursuit of objectivity, which has reduced modern journalism to meaningless he-said/she-said, can be equally damaging to software. Flexibilty is often the enemy of good design. Take Apple as another example. Frequently, there is only one thing to do things: Steve Jobs’ way. Sometimes I’m frustrated by that singlemindedness. Sometimes I think he gets it wrong. But most of the time he gets it right, and I think that is why the products are brilliant and well-designed, and a joy to use. Steve’s (and Jonathan Ive’s) biases deeply encoded in the DNA of the product. Apple celebrates those biases. They don’t try to be all things to all people.

We should embrace these constraints. DHH argues that it is precisely this approach that makes Rails as easy as it is. He says, “The closer your opinions on web-application development are to mine…, the more Rails will feel like the perfect fit.”

So recognize your biases and try to make the right design decisions, rather than just coding more arbitrary flexibility. Become comfortable with the idea that there is a set of people who should not buy your product. Instead, focus on making the best possible decisions for the people who should.