Disagreeing With 37Signals #2: Opinionated vs. Stubborn Software

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:


Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Disagreeing With 37Signals #2: Opinionated vs. Stubborn Software


This is the second in a series of articles taking a look at 37signals and more specifically, their book Getting Real  As I’ve said before, I mostly like what the 37signals folks have to say in the book and agree with a large part of it.  However, I didn’t think an “agreeing with 37signals” series of articles would be particularly useful.  In any case, if you haven’t read the book yet, I’d recommend it.  
In my last article, “Less Is Sometimes Less”, I made an attempt at explaining why the 37signals model of keeping things simple and including less features doesn’t make sense.
I didn’t do a particularly good job of explaining my position that time, but to summarize my point:  It’s important to pick your target market and focus.  On this, I think most people agree.  In the article, I talked about word processing software and why a journalist might need something different than a book author.  My point was that once you’ve picked a target market, it is important to deliver at least the minimum set of features that make sense for that market.  By not picking a market, you end up making one of two mistakes:  you build so little features that hardly anyone’s needs are satisfied, or you build too many features, because you’re trying to serve everyone.  In any case, that was that article.
This time around, I’d like to look at the concept of user preferences (which is discussed in a chapter in the book in the “Getting Real” book).  
We’ll start with a simple example and excerpt from the book:
From “Getting Real”:
Decide the little details so your customers don’t have to.  You’re faced with a tough decision:  how many messages do we display on each page?  Your first inclination may be to say, “Let’s just make it a preference where people can choose 25, 50, or 100.”  That’s the easy way out though.  Just make a decision.
Now, the point about taking care of the details for a customer is a good one.  Customers shouldn’t have to worry themselves over a ton of minutia that they don’t care about.  However, we have a term for this in the software industry.  They’re called defaults.  So, I would suggest (as 37signals does), that we should write opinionated software.  It should make some choices on its own and not burden the customer with these.  However, if the software makes these choices and doesn’t let us change them, its not just opinionated, its stubborn.  Asking the development team to make some of these choices (like showing 25 messages per page) seems a little misguided.  To suggest that this is a “best practice” is misleading.  
I also disagree with the fact that making certain things a “preference” is the easy way out.  It’s not (as they go on to explain later in the book).  Making intelligent choices and allowing for reasonable ways for customers to change the behavior of the software to fit them is most decidedly not the easy way out.  The easy way out is what 37signals did: 
”…That’s what we did in Basecamp.  The number of messages per page is 25.  On the overview page, the last 25 items are shown.  Messages are sorted in reverse chronological order.  The five most recent projects are shown in the dashboard.  There aren’t any options.  That’s just the way it is.”
This is what I would call stubborn software.  Sure, all of those choices are fine choices, as defaults.  But what if my monitor resolution allows me to see 100 messages? I’m now clicking more than I need to on an application that I might be using all day.  What if I want to sort messages by author?  Nope.  What if I only have six projects in my company and I’d prefer something them all in the dashboard.  Nope.  I have a hard time believing that this is all “better for the customer”.  Simplicity is a wonderful thing, but confusing simplicity with lack of capability is dangerous.  
A summary of my point:  Customers often prefer preferences.  They like to change their software to work the way they do.  Simplicity can often get their attention early on (if there are no better alternatives), but if it’s too simple, they’ll become frustrated over time.  Frustrated customers are not a good thing.  Strive to make your software opinionated, but not stubborn.

Posted by Dharmesh Shah on Thu, May 04, 2006


Options are good sometimes. They have an associated cost, however:

1. They make the interface more complex for the customer to use

2. It will take time to implement them. This time could probably be spent on more important things.

I don't think that having no options at all isn't right, but most times simplicity is more important than customizability.

posted on Thursday, May 04, 2006 at 11:53 AM by Jules

Preferences are a good thing, but shouldn't be built from the start. Start with simple software, and respond to users' needs when they ask for a preference. There's no point in building 100 preferences when all they really need are 4. I think the point is to have as few preferences as necessary, based on customer demand. Over-preferencing is one of the greatest causes of bloat.

There's a middle ground to be found between the two, obviously. 37signals specializes in simplicity- the opinions they have on their software should be things to keep in mind- not rules to live by.

posted on Thursday, May 04, 2006 at 1:20 PM by

Joel Spolsky wrote on that subject in his series:

Tite: "Controlling your environment makes you happy".

While this can be dangerous (windows task bar being too easy to resize) it's also necessary for people to feel they use 'their' program, instead if 'your' program ;)

posted on Thursday, May 04, 2006 at 4:47 PM by Marcin Brzezinski

Stubborn software from stubborn people:

posted on Thursday, May 04, 2006 at 5:24 PM by

I think what 37Signals might forget is that users interact with, and feel about, software as tough the software were human - they love it, they hate it, they get angry at it, they feel victorious over it, they get offended, they feel disenfranchised, they feel understood - basically they develop personal feelings towards the software, independently from their level of expertise. I have observed this behaviour in myself and others quite often.
Therefore, the same principles as project managers or salespeople have to follow also apply to software (in a way): While it is true that as a salesperons or a PM you scare away clients if you ask them to make 200 decisions before you even start the first project, the opposite might be even worse. Do you think an account manager who answers any client suggestions or queries with "sorry, but that's the way we do things here" or "look, this is how we work, no matter what you say" would be a good account manager?
I think you have to look at user interfaces the same way you look at people who deal with clients - and combining flexibility and simplicity is a challenge. Don't overwhelm clients - right - but don't disenfranchise them either.

posted on Friday, May 05, 2006 at 7:50 PM by Chris

Most of the time preferences are gadgets. Of course, customers often like gadgets, even if they don't need them. They like to change their software to their fancy, but to acheive results what they really need is tools to work efficiently. Removing unessential preferences permits them to focus on what really matters. Customers lost playing with features are not a good thing. They are maybe happy at first, but sooner or later they will rate your tools based on actual results. Strive to make your software efficient, not bloated with gadgets.

posted on Thursday, June 01, 2006 at 3:28 AM by S. Gagnon

Comments have been closed for this article.