
Joel Spolsky video – Simplicity is a way of avoiding looking like you lack value - marklittlewood
http://thebln.com/2011/11/joel-spolsky-at-business-of-software-2009-simplicity-is-a-way-of-avoiding-looking-like-you-lack-value/
======
statictype
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.

~~~
Duff
Features don't necessarily translate into more complexity.

~~~
revorad
Actually, they do by default. It takes extra work to maintain simplicity while
adding features.

~~~
Duff
Sorry about my mangling of the english language!

From the end user's perspective, features often reduce complexity, sometimes
dramatically so. Before "mail merge" was a common MS Word feature, collating
form letters was a tedious job.

Good engineering and design integrates features into the application in a way
that avoids complexity.

~~~
ams6110
Yet even something as straightforward as mail merge is a hurdle many MS Word
users cannot clear, at least not without out a call to the help desk.

------
agentgt
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.

~~~
DannoHung
> 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.

The 1984 commercial wasn't intended to state that every individual computer
should be different, but that you should be able to do different things with
your computer than just the business applications that were prevalent.

~~~
agentgt
Actually I wasn't really focusing on their software but their hardware (my
wife wants the iPhone in gray to match her coach pocketbook). You can actually
customize Mac OSX far more than you can customize gnome shell.

I was merely making fun of Apple's crazy licensing for the App Store, their
lack of respecting privacy, the fervent fanatic love for them, and that a
majority of the users that use Apple products are of a particular demographic
all of which to me is very very 1984ish.

Just ask Bret Victor: <http://worrydream.com/#!/Apple>

Hey I will say that the MacBook Air kicks ass!

------
j_baker
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.

~~~
fmavituna
I think what Joel argues that you can keep things simple but keep adding
features. Granted that's really hard to keep the balance but it's doable.
Simplicity is hard, keeping it simple while adding new features is even
harder.

> Startups simply don't have the time or resources to create complex products,
> at least starting out.

Completely agree. It's one of the easiest things that a startup can provide
(assuming there's talent within the company who can deliver that simplicity.
All developers know by now delivering simple and usable software can be really
hard)

------
nadam
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.

------
mcgwiz
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.

------
clyfe
This is [2009] add it to title.

------
spanktheuser
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.

~~~
r00fus
> 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.

Do you have a reference for this? In my personal experience, very few people
are using the new list feature.

------
tlogan
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.

------
mtkd
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?

------
dextorious
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.

~~~
jiggy2011
It may be popular to hate VB, but it was certainly much simpler to develop
with than the C++ Windows SDK was at that time. Surprisingly powerful too. I
remember building both a point/click adventure game , a poker game and an
organizer app from scratch without any formal CS education.

From what I remember Joel was responsible for VBA, which brought programming
to people who had no idea what a pointer was. Of course this spawned some of
the most badly written business apps out there, but that's hardly his fault.

Are they still using their own compiler? Never really understood the reasoning
behind that , I believe it was to make it compatible with Windows and Unix,
but surely they could have simply written the app in php and bundled it with
apache all statically linked together?

Pherhaps CityDesk was not the best thing ever, but nobody gets it right every
time.

~~~
ams6110
IIRC they wanted to make an existing ASP app (FogBugz?) and be able to sell it
to Unix shops, ergo a cross-compiler that spit out PHP from ASP. They did not
want to maintain two distinct codebases. From that, it evolved into an in-
house bespoke development language.

Also IIRC, in its day CityDesk _was_ a fair bit simpler than other website
management systems.

------
dekken_
I don't even like the grammer.

'to avoid looking like'

Would be better.

