
80-20 software - fogus
http://www.johndcook.com/blog/2012/07/22/80-20-software/
======
skibrah
Designing for the 80% case is especially important in mobile, where cluttering
the user experience with small, seemingly nice to have "features" ends up
turning a smart, functional application in to a confusing piece of software.

------
greenyoda
Whether you can get away with building 20% depends on what kind of software
you're selling and who is buying it. In the enterprise software world your
customers are going to have a check-list of features, some of which are
useless or redundant, but they happen to have been implemented by your
competitors. If you don't implement those features, you may not even get your
foot in the door.

There are lots of other areas where you would be killed if you tried to sell
just the 20% of core features. For example, a "20%" smart phone probably
couldn't compete against a fully-featured iPhone or Android phone.

~~~
johndcook
Good point. I believe that explains why a lot of software is so bloated. It
got that way for good reasons, at least what were good reasons at the time.

------
greghinch
Putting aside the kind of silly hypothetical exercise of trying to figure out
which 20% of features to develop, the rest of this I feel is spot on. As a
developer, so often I either come into applications with redundancy or get
directed to build redundant features in. Often the person who makes that
decision has no real basis, they just want to make sure people can use feature
X, so it seems like putting in 3 different ways to do X makes sure everyone
will use it. In reality, you are just adding overhead for your team and
confusion for your users.

------
rwmj
One way to mitigate this is to reduce the cost of maintaining those little-
used features.

I've been doing this by (a) having a huge automated test suite that covers
just about every feature (you don't get a feature in unless it has a test),
and (b) being very aggressive about generating code, and (c) using Coverity to
automatically find bugs.

The automated tests (a) let us know if a little-used feature breaks because of
an unrelated change. That lets us decide whether to remove or fix the feature
without the feature being a constant burden. Generating code (b) lets us make
global changes to boilerplate without micro-managing each feature. And using
code quality tools (c) is self-evidently better when you have a large
codebase.

------
deafbybeheading
This reminds me of Alan Cooper's "The Inmates are Running the Asylum," where
he argues that you can't please everyone and you should not be designing an
application to solve all possible use cases because that's doomed to failure
(or, at best, mediocrity). You can do better making a killer solution for 80%
of your potential users than you can trying to address the needs of all
potential users.

------
Metrop0218
Yeah this is an interesting discussion. I usually stand on the side of one or
two features done really well at first, then adding more as time goes on and
needs arise, but always make these less used features more hidden in the UI.

However I think most people tend to use that train of thought, not so unique.

------
johndcook
There's a follow-up post addressing some of the arguments given in the
comments to the first post:
<http://www.johndcook.com/blog/2012/07/23/80-20-software-ii/>

------
polemic
Of course, you might just find that 80% of the users you have left still only
use 20% of the remaining features, so you should naturally recurse until
you've left with just an empty <html> tag.

------
erichocean
80% of users all use a different 20%, which is why you build the entire 100%
of the software. ;-)

~~~
snprbob86
You know, I've heard this "fact" quoted over and over again, but it ignores a
simple reality: There exists potential, unimplemetned features which _no one
can possibly be using_ , but would! If you had fewer features, you'd still
have 80% using a different 20%. Whose to say if you'd make more money or have
happier users?

