

The Importance of Simplicity - abi
http://abcdefu.wordpress.com/2009/05/08/simple/

======
abi
I'm the author of the blogpost and I feel I didn't write enough about how I
differentiate simple and complex. Here's a good but very software-specific
example that might illustrate that. Imagine you told a programmer (or team of)
to create a Digg clone. How many of them would build the entire system with
all the features (submissions, comments, friends, profiles, media types,
categories, etc.)? I'll wager that most people will attempt to do so. As a
result, they'll probably fail. That entire Digg "system" is what I would call
complex. On the other hand, when given such an assignment, you should try to
write something simpler which would at once also be useful. In this case,
write something like Hacker News (but take out comment threading, karma and a
few other things)! Once you're done building that, you can slowly add
profiles, categories or whatever would benefit the community the most. That's
the meaning of "start simple, use a lot and evolve"

Another thing, it's important to remember that what was complex yesterday is
simple today as we move to a higher-level of abstraction.

~~~
jzachary
In the academic/applied research setting, I find sensor networks are the
canonical example of this phenomenon. People jump off into "secure energy-
efficient self-organizing" sensor network architectures, that they lose the
ability to even articulate the problem they are ultimately trying to solve.

------
swombat
Very good article, and very true for start-ups.

I am always skeptical when I hear someone describe their start-up and it
sounds really complicated (especially if they haven't launched yet).

I suppose it is possible to deliver complex systems that work for users, but
it's extremely hard. And it's already very hard to deliver even simple systems
that work for users, so if you like to change your 1% odds into 0.01% odds,
either you have money/time to burn, or you're making a bad gamble.

~~~
jzachary
Echo that sentiment. When I hear an overly complex solution or idea, I think
that person either doesn't know what they are talking about or that the
solution is for a hyper-niche situation. Usually, asking a few "Heilmeier-
type" questions will lead to classifying the person in the former group.

And I admit to being a member of the former group myself, too often, I'm
afraid.

~~~
swombat
What are "Hellmeier-type questions"?

~~~
jzachary
George Heilmeier was a former DARPA director, for whom the Heilmeier
Cathechism is used by DARPA PMs to judge projects. These simple questions are
excellent for understanding other projects, and I use them to keep my own
projects on track. I also use them as the basic outline for presentations.

[http://en.wikipedia.org/wiki/George_Heilmeier#Heilmeier.27s_...](http://en.wikipedia.org/wiki/George_Heilmeier#Heilmeier.27s_Catechism)

------
mixmax
_A complex system that works is invariably found to have evolved from a simple
system that worked. The inverse proposition also appears to be true: A complex
system designed from scratch never works and cannot be made to work. You have
to start over, beginning with a working simple system._ this isn't always
true.

Basically you can do two kinds of products: evolutionary and revolutionary.
Evolutionary products can start as something simple and evolve into something
more complex. They are the ones we usually talk about because they are easy to
do, and make up the bulk of all digital products.

Revolutionary products are the ones that can't evolve from something simpler
but have to be complex from the start to serve a meaningful purpose. The
Apollo space program is a good example: It probably wouldn't have worked very
well if they "launched early and launched often" and fixed problems as they
went. It would also require too many suicidal astronauts ;-) It had to be
perfect the first time. It's basically the same issue as irreducible
complexity in evolution: All the intermediate steps have to be useful, or you
won't ever get to the finished product. Incidentally this is also why you
don't see moving parts such as wheels in biological organisms: The steps
leading up to it are no good. Aeroplane manufacturing is the same thing:
Either it works or it doesn't.

The areticles advice pertains only to evolutionary products and startups.

~~~
stcredzero
_The Apollo space program is a good example: It probably wouldn't have worked
very well if they "launched early and launched often"_

Actually, they did iterate and take small steps. They started with unmanned
suborbital launches, went to manned suborbital launch, then manned orbital
launch. And that was just the Mercury program. Next, they went to launching
2-man capsules, spacewalks, and on-orbit rendevous in the Gemini program.

 _It would also require too many suicidal astronauts ;-)_

You have an implicit assumption that rapid iteration means poor quality
control. It doesn't have to. I've met people with _formal methods_ tools who
say they are capable of rapid iteration. (And yes, these are marketed to the
aerospace industry.) Also, if you manage a project from the start with
automated testing, low defect rate is very doable.

 _Aeroplane manufacturing is the same thing: Either it works or it doesn't._

Uh, no. There are _lots_ of examples of planes that _kinda_ worked. This is
why test pilots have to be so good. You have to be very good to get a kinda-
working plane back on the ground in one piece, or sometimes even to just
manage to eject from it.

Your point may be good, but it suffers from drawing from examples which you
don't have very good knowledge about.

~~~
mixmax
Sorry about the examples :-)

And reading yours and the other comments in the thread, I'm not so sure I'm
right. Oh well, you learn every day...

