
Daring Fireball: Complex - dmytton
http://daringfireball.net/2009/04/complex
======
sachinag
If Apple has learned anything with the iPhone, they've learned it from
Nintendo's Game Boy strategy.

When the Lynx and Game Gear came out, it _had_ to have a bigger, color screen.
It _had_ to have more buttons. It _had_ to have a bigger storage unit.

And yet, Nintendo made calls - we could do these things, but battery life
would suffer. And no one can play something that's dead.

And then, when Sony decided to go after the Game Boy Advance with the PSP,
Nintendo said "let's make a new device, not a better Game Boy." Even now, I
submit only two games get everything out of the hardware: Phantom Hourglass
and Chinatown Wars. But things like Nintendogs and Brain Age make such good
use of the touch screen - the zigging when the obvious zag was to support more
colors, more storage, and more functionality (MP3 playing, Skype support, etc)
to compete with the PSP - that they've outsold the PSP 2-to-1. (And let it be
said, the PSP is a massive, massive success that no one talks about - you try
selling 40 million of _anything_.)

I'm really excited about the Pre, but if its battery life isn't better than
the iPhone's, it'll die and it'll die quickly. Users can live with well-
designed compromises.

~~~
unalone
Nintendo is a terrific company to compare Apple to. They have a similar grasp
of the gaming industry that Apple does of the tech world, and it's why they've
had such an edge designing. Similar to Apple, they go unexpected directions,
and other companies don't seem to get why it is that they surge ahead. They
assume it's because of "gimmicks," and add similar gimmicks to their products.
Look at how SIXAXIS went compared to the Wiimote and you see something similar
to the touch phones that non-Apple companies released to beat the iPhone.

It's worth noting that Nintendo is an outright slaughterhouse in terms of
sales. In the top 50 weekly VG sales, they have 18 in-house games. 6 of the
top 10 (10 of the top 15) are for Nintendo consoles. Only one other company
has a game on the list that's sold 5,000,000 copies. Nintendo has 13. Things
like that are why I laugh at people who say the 360 isn't that far behind the
Wii, because the Wii is in a universe unto itself.

~~~
madh
I read your post and had to go look up some the numbers. \- 28 million 360s
sold since 2005 \- 50 million Wiis sold since 2006 \- Nintendo has sold 2.7
billion games to date

~~~
unalone
It's insane. Game magazines were writing about how "no company survives past
the second generation" and how gaming was hardcore and nobody wanted to play
video games and gamers were super elite. Then the Wii was announced and the
reaction among gamers was universally "nobody wants to play games that are
basically toys." I was a Nintendo fan, Gamecube and all, and I had lots of
yelling arguments with my friends* over how the PS3 was awesome, but the Wii
would blow people's minds. I love that it succeeded, because Nintendo and its
corporate culture deserve that kind of success. (PG wants to write about the 5
best people in start-ups? Shigeru Miyamoto takes my #2 slot. He designed not
just the systems but the games, and he's an incredible human being.)

*That was in high school, of course, where people have those ridiculous gaming arguments. Now I'm in college and my superathlete roommate just bought Pokemon Diamond on eBay.

------
nickb
Initial iPhone was anything but simple! First gen iPhone was YEARS in the
making and rests upon decades of Cocoa engineering. Gruber is completely off
the mark in that regard and is overplaying his hand. Every company iterates.
Even MS iterates and evolves an initial product and you can see that with
Windows 7.

There are lots of reasons for success of Apple but the thing he stated isn't
one of the major ones. Apple loves to work in vacuum with no user feedback
whatsoever since SJ likes to say that 'people don't know what they want until
they see it.' To have a truly evolving system, you need to have a user
feedback loop and Apple has one of the worst feedback loops in the industry
since they almost never act on feedback and when they do, it takes them years.

~~~
cubicle67
Prior to the unveiling of the iPhone there were a large number of people who
attempted to guess what an Apple phone would be like. Loads of high quality
art was produced by lots of very talented people.

And guess what? _Nobody_ foresaw anything like what the iPhone ended up being.
Most people couldn't get past trying to fit a phone into a click-wheel iPod.

Do you seriously think the iPhone would have been better if Apple had asked
people what they wanted?

~~~
nickb
>Do you seriously think the iPhone would have been better if Apple had asked
people what they wanted?

That has nothing to do with the article's argument that Apple's secret is
evolution of simple systems.

As for your point, each approach has its virtues. What works for Apple
probably won't work for the rest of us. Apple has hundreds of brilliant
designers that create three different _pixel perfect_ designs for each piece
of new UI. Three different teams (and all brilliant at what they do) working
against each other... how many of us can afford something like that?!

I still contend that Gruber's argument about Apple's secret being simplicity
and evolution is bullshit. He probably came across Gall's law and decided to
spin it into an article about Apple.

~~~
unalone
So you think that Apple makes good designs just because they're a large
company? I've got news for you: the companies they compete against are much
larger. Dell and Microsoft could easily afford more designers than even Apple
has. The products they churn out are still comparatively worse.

You'll notice that Gruber mentions the period in the 80s where Jobs was still
an employee as a period which saw similar results. This is not something that
requires a huge team. Back with the original Macintosh there was a similar
effect. I would hope you've seen the computer's initial unveiling - it's on
YouTube - because that's a video that inspires me to this day. Younger,
tuxedoed Jobs reveals it, begins using it, and the audience begins half-
screaming, in a near-frenzied way. They can't believe that they're seeing what
they're seeing. And that's the startup Apple, that's the two-man operation.
Back when they didn't have as much in terms of resources, they still focused
on creating that simple core, because that's what people care about.

You think simplicity and evolution is a bullshit concept? Not that I know
anything about you or the stuff you've worked on, so apologies if this sounds
ignorant and facetious, but that's at the core of making _anything_. That's a
"secret" that I stumbled upon independently. I know a lot of programmers who
came upon that - and I find that I respect their work much more than I respect
the work of people who don't "get it".

Look at NewMogul. Do you think that if that site was started by Paul Graham it
would be as small as it is right now? No, not because Paul Graham necessarily
has a publicity advantage, but because if he were making it he'd most likely
go about making it tied in with Hacker News. HN is his simple core model, and
NewMogul could be seen as an expansion of that initial concept. As a concept
of its own, it's failing - if you wanted to make a huge site for business-
interested people, cloning Hacker News is not a smart idea. So the failure
comes down not to the design, because the design is quite pretty, but to the
concept, which is not simplistic enough to work.

------
pg
"How small? How simple?"

We advise startups to launch when they've added a quantum of utility: when
there is at least some set of users who would be excited to hear about it,
because they can now do something they couldn't do before.

~~~
boucher
Apple doesn't release simple things because they wanted to ship as fast as
possible. In fact, I'd say Apple behaves in the opposite fashion. They take as
long as necessary to release something intentionally simple. Arguably the
iPhone started out as a hugely complex system that needed to be paired down to
what was really essential.

~~~
10ren
For example, they pared down Flash, and therefore YouTube. It seems like a
crazy omission, but it hasn't stopped them.

I'd guess they omitted Flash because the iPhone is too low-powered for it to
look good; the iPhone needs optimized native apps. Since "looking good" is a
huge part of the iPhone experience, it makes (painful) sense to drop that
feature. Same for Java.

It seems they couldn't justify omitting Javascript too, but I bet they would
have loved to, as it's 78-90 times slower than a desktop iMac:
[http://arstechnica.com/apple/news/2007/08/iphone-
benchmarks-...](http://arstechnica.com/apple/news/2007/08/iphone-benchmarks-
suggest-javascript-performance-deficits.ars)

~~~
boucher
Well, those benchmarks are over a year and a half old, and the JS engine in
webkit has improved by probably a factor of 10 since then. iPhone 3.0's
JavaScript will probably be a mere 10 to 20 times slower than Obj-C, which is
actually pretty trivial for most iPhone apps.

~~~
10ren
You've missed my point: those benchmarks confirm how underpowered the iPhone
was/is, and provides support for the hypothesis for omitting Flash and Java.
This relates to the article's suggestion of starting with the minimal feature
set, and iterating. And your own point of "paring down" the feature set.

It might sound like I'm criticizing the iPhone, but I'm not: it's how Apple
managed to create a cool experience for users in an incredibly compact size
(they are _tiny_.)

The result is that when Moore's law does enable reasonable processing power in
a device that small, Apple will be in the best position to exploit it, in
market position, in design tradeoffs, and in engineering knowhow.

------
jimbokun
'The “phone” in “iPhone” is much more about ubiquitous always-on wireless
TCP/IP networking than it is about the 20th century conception of telephony.'

Recently, my 7 year old son asked me "Dad, can you call people with an
iPhone?"

(We don't have one, but he sees the commercials on TV.)

------
jhawk28
Creating a simple framework to build on is probably the best way to create a
compelling complex product. One can see this pattern in other things such as
RoR - Basecamp, XUL - Mozilla, etc. Over time they seem to become more
complicated and people move on to other things.

~~~
neilc
Your examples seem about as strangle as Gruber's. The initial releases of RoR,
XUL, and Mozilla were not "simple" by any stretch of the imagination (RoR was
less complex than XUL/Mozilla, but still much more complex than many other web
frameworks).

~~~
unalone
Simple doesn't mean lacking complexity in terms of code. It means lacking
complexity in terms of usage.

Say what you will about Rails, but people using it can develop things pretty
incredibly quickly, and there's not an enormous learning curve. That's
simplicity.

~~~
10ren
Creating a platform that can be built on is the way to go - but it seems very
difficult to create one that is simple to use, that can generalize in the
right ways, and enable people to build what they want.

But maybe that's not the trick - it isn't that hard to make an overgeneral,
loose platform, that isn't specialized towards any particular usage. Maybe the
particular platform isn't that critical. Maybe the trick is just to provide
_access_ to something that is really cool and exciting (that simple core
idea). Developers are clever, they'll work out how to get on the bus.

I'm not sure if this applies to Rails.

~~~
unalone
Well, Rails is focused on this idea of doing things the Rails way. So you lose
a lot of that generalization that you'd get by, say, programming everything in
Ruby. But in return, you get the ability to develop and iterate extremely
quickly, because a lot of the stuff is set up in advance.

I'm not entirely sure what you're saying, though: could you elaborate a
little?

~~~
10ren
_ACCESS_ I was saying two things, one you saw a refined version of elsewhere:
"making it exciting is more important than making it easy to develop for".
Designing a great platform (in terms of the insides being usable for
developers) doesn't matter if the platform does something great. Many sins are
forgiven if you have this. I think there are probably many examples of
horribly ugly technologies that became wildly successful because they enable
access to something exciting (DOS? windows? netscape navigator?)

 _USABILITY_ To elaborate on the other idea: it's much easier to make
something usable if it has a specialized purpose. Fewer features, fewer
interactions/interdependencies, fewer controls, fewer things to go wrong -
it's gonna be simpler to use. e.g. ipod shuffle. That is, _not being able to
do things_ makes it easier to use.

The big problem with a platform is that you don't really know what the
specific use will be, nor the exact nature and parameters of it. A _platform_
, by definition, is general, and not specialized to one specific purpose. And
you won't even know the nature of the _general_ use. Except, perhaps, that it
will want to be part of whatever the cool, exciting thing you have going is -
that's a predictive organizing principle.

Therefore, for a platform, rather than trying to guess at the kinds of uses it
will have, maybe just say: (1). what is the cool, exciting thing that we
enable? (2). how can we let developers build something that has that cool,
exciting thing? That is, an API that gives them access to whatever they need
to do that. It doesn't need to be great access, they just need to be able to
do it somehow.

This is "overgeneral" in the sense that you can not only do the things you
want to do, but you can also do things you don't want to do. This looseness
makes it harder to use - if it was an exact fit to the problem, it would be a
delight to use. This extra power gives you "enough rope to hang yourself".

 _RAILS_ On reflection, I think Rails is a much later stage in the development
cycle: webapps are in a more mature stage, and by that I mean that people now
know what kinds of things they want to do, and most importantly, what kind of
defaults are useful. At an earlier stage, we didn't have enough collective
experience to know those things. This knowledge is to do with how webapps
appear to users externally, as well as what architectures and internal
approaches have been found to work. Webapps are becoming an understood art,
when previously, it was a bit of a black art.

Rails represents a systemization of webapps; no longer ad hoc, many design
decisions are now captured in a mechanical tool. It is specialized to the
task.

------
javanix
Apple is also one of the few companies that comes out with unique hardware.
When you can start from your own simple designs it is possible to engineer
unique and genuinely more useful hardware (see: the new battery in the 17in
Macbook Pro).

Unfortunately, the cost of developing from the base case as described in the
article is very high - and reflected in Apple's prices.

------
philwelch
"The problem with Apple in the 90s was that they stopped doing this. The Mac
had a great run from its debut in 1984 through the end of the ’80s, where both
the hardware and software improved every year. Then that stopped."

Even that is somewhat misleading. The original Macintosh operating system was
designed specifically for singletasking on the original Mac 128k hardware--a
design choice that hamstrung Apple for years afterwards, and became the root
cause of Apple's need to completely replace their operating system. It's not
that Apple gave up on incremental development and started on quixotic missions
to the next big thing. It's that the system architecture of the Mac OS was
years past its prime and Apple couldn't fix it iteratively anymore.

------
fleaflicker
Fleaflicker is evolving using the same idea.

The other advantage to this approach is mental. If I knew how much effort it
took to get to this point I would have never started.

------
Tichy
Daring Fireball == glaring fanboyism.

~~~
rimantas
Far from it. Daring Fireball—best writing abbout all things Apple you can find
on the net. When I see DF post marked with a star in my RSS reader I know that
high quality read waits for me, with some work, thought and insight put into
it. Or maybe I am just a DF fanboy…

~~~
unalone
I'm a DF fanboy _and_ an Apple fanboy. For me fanboyism means realizing that
something's good enough to be a fanboy about.

Gruber's a Mac fanboy, but he's also one of the most critical Mac users I
know, along with John Siracusa. When Apple does something bad, Gruber is vocal
about it. He's still critical of a lot of OS X's interface, and writes about
it often.

~~~
earthboundkid
Gruber's response to Apple announcing the original iPhone "SDK" ("Just make
web apps for it… With AJAX and stuff.")?

"Shit sandwich."

So, yeah, Gruber knows when to call a spade a spade.

------
nessence
"store" simply doesn't exist in this article

------
access_denied
"It’s not enough just to start simple, you have to start simple with a
framework designed for future evolution and growth."

Vi vs Emacs? The former lacked extensibility, so it kept being a "phone".
Until the mighty Vim came along...

