Joel Spolsky video – Simplicity is a way of avoiding looking like you lack value

Joel has said in the past that nothing has increased sales more than adding new features. I've always wondered how he reached that conclusion and what data he used to arrive at that. (it doesn't necessarily follow that if subsequent releases generated more sales and had more features, then it's because of those features that sales were made).

Generally I've found that simplicity may not create marketing buzz for your product but will result in more people actually using it (sadly people using != more sales all the time). That's why people still use excel instead of the enterprise crm/erp system that their COO bought.

I have found the recent trend of lets "simplify" everything cause Apple did it at times annoying. Take for example the Gnome 3 shell. Most Linux users want "options" and don't mind complexity otherwise they would buy a Mac.

I find it ironic that Apple has prided itself with "Think Different" and break away from big brother (for those that remember the "1984" commercial) when apparently Apple prefers homogeneity instead of uniqueness.

I almost completely disagree. To be fair, I don't doubt that there are companies use simplicity as an excuse for not adding value. At the same time, there are at least as many companies out there that pack feature after feature into their products, then find themselves asking "Why is no one using my product? It can do so many things!"

The fact of the matter is that simplicity is a value. I suppose one could argue that it's a somewhat overrated value. But for startups, it's the most important value. Startups simply don't have the time or resources to create complex products, at least starting out.

I think it depends on the market. There are some markets where complexity is really a pain. There are other markets where existing products are already simple enough for the given users that this is not the main concern.

Unfortunatelly in markets where complexity is a huge pain nowadays it is very hard to find or build the relatively simple solutions. Otherwise others would have found/built it already.

So yes, yet another bug tracker will not win in the market just by being even more simple than the other simple bug trackers.

But in a market where users are actually fustrated of the complexity they have to deal with - it can hit big. For example in case of programming languages, frameworks it is a big selling point to be simple: programming can become fustratingly complex if the tool is not designed with simplicity in mind (see enterprise Java). That's why things like Ruby on Rails are successful.

A better title might be "simplicity is used as an excuse for creating worthless software."

But anyway, Spolksy basically advocates finding the "elegant" solution, which is the one that incorporates useful features in an easy-to-use way. Hardly a controversial position. However his use of the word "simple" consistently conflates feature-poorness (lack of features) with ease-of-use. So when he says focusing on simplicity results in worthless software (as indicated by actual sales), he appears to attack ease-of-use. He's not. He's only attack feature-poorness. Cue confusion and controversy.

This is [2009] add it to title.

Simplicity and features are related, but they aren't opposite ends of a spectrum. I tell my design and product team that as the core feature set grows, more development time and design effort must be invested in keeping the software simple to use. Similar to the way your test suite must grow more powerful to cope with increasing code complexity. There's probably a cool metaphor like technical debt lurking around here somewhere.

As an example, think of Facebook - one of their ideas was to simplify the standard classes & permissions system down to concept everyone would understand and use: Friends. Friends is basically permissions without the classes, wrapped around a familiar mental model. This was very successful, but over time users demanded the ability to grant different permissions to different users. For example, family vs. applications or close friends vs. co-workers.

So Facebook re-introduced the concept of classes to their permissions systems. They called them lists. And they ran into the same problem that has bedeviled permissions systems from the dawn of Unix. It's a PITA to understand and manage the additional complexity.

So Facebook invested a lot of time in simplifying class management. Namely, they used social signals, some basic heuristics (everyone has a class called "applications" and another called "family") and probably some other information to auto-assign friends to classes for you.

While the new, class-aware permissions system is more complex than what Facebook started with, it's simple enough that users seem to be adopting it just fine.

This is just one example, but this sequence is repeated everywhere good software is made. And it's pretty easy to understand: stop adding features when they add too much UI complexity for your target audience to successfully use. Assuming you're not doing monolithic releases and are capturing lost of user feedback, you'll know when you're about to cross the line.

Actually, the most important thing to increases sales is "it must not suck".

It seems like we are parsing "simplicity" too much lately. It is not "simplicity"; it is "it works".

Starbucks is not successful primary because their coffee does not give you diarrhea.

Oracle DB is not successful because they were the fastest or more features: it actually worked better than other RDBMS on the market.

I can also mention SAP (super complex - but it works), etc.

Please don't think your customers are stupid. They can handle complexity if your thing does the job well.

It's a cycle.

1) Someone builds a product

2) Feature creep

3) Next gen comes along and builds a simple variant with only critical features

4) Feature creep

5) back to 3

It's human nature to want to 'improve' something. With software that invariably means more features. New managers/owners of any project usually arrive with a shopping list of improvements - because more features = happier customers right?

I'm not sure I'd want advice on the value (or lack) of simplicity, from someone who is in part responsible for Visual Basic, and has two main products that are far from either top notch or tremendous financial successes and which are coded in a monstrous ad-hoc compiler that spits out PHP and/from ASP.

That said, he has written several good project management essays --if you skim though all his bullshit UI and interview advice. I mean, UI advice from the man responsible for CityDesk??!

Well, at least you can't fault his very good mercurial tutorial, or Stack Overflow.

I don't even like the grammer.

'to avoid looking like'

Would be better.