Hacker News new | past | comments | ask | show | jobs | submit login
Daring Fireball: Complex (daringfireball.net)
76 points by dmytton on April 1, 2009 | hide | past | favorite | 40 comments

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.

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.

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

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.

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.

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?

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

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.

As someone who loves design (and is not very good at it): it's interesting how simple the iPhone appears after seeing it - but to design something like it before seeing it is something else...



I think Gruber's main point is that it could have been much more complex - people could think of dozens of extras, for both the mac and iPhone. "So where do you draw the line?" he asks. Add everything essential for it to be its basic cool thing, and stop. The features serve one purpose; they aren't an end in themselves. It's a kind of integrity.

Apple went Exupery on the shuffle too, reducing it to the minimal feature-set.

Well, it was simple relative to other smart phones. Not simple relative to a phone phone, sure.

Simplicity and sophistication of the UI/UX has nothing to do with the simplicity of the overall system. Underlying system is probably more complex because the UI/UX is simpler.

So maybe Gruber should have said that UI is simpler, but not the iPhone. If iPhone is so simple, why aren't other big companies as successful at creating new phones? Clearly, things are not as simple as some people would make you believe.

Also, a jump from Razr or Palm (for example) to iPhone is much bigger than that of iPhone 1.0 to 3.0.

Had Apple released a Razor-like iPhone and then iterated to iPhone 1.0 system over a year or two, I'd buy Gruber's argument. But iPhone was clearly 'from the future' when Apple presented it and everyone else was scrambling to catch up. So Gruber's argument is not really serious.

You can't "iterate" to the iPhone. That is his point. The iPhone is a core concept that you can't get from iterating. It's a basic phone model that didn't exist before.

Other companies aren't as successful at making new phones because they're reluctant to abandon everything they have to create new systems and models. Their minds are stuck in a single pattern. Nobody making those mock-up sketches for the iPhone thought that Apple would get rid of a numberpad. Nobody. Every indie designer making a mock phone kept the numpad there. You can't necessarily throw lots of people at a concept and expect it to be better. It takes a certain moral bravery to get rid of everything and start anew.

The article uses Microsoft as an example of iterating (from Windows 3.0 to Windows 95).

agreed, this is not a good metaphor

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

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.

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

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.

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.

I think this advice matches up really well to one of the things you say in your "5 Founders" essay about Paul Buchheit:

"PB made a point in a talk once that I now mention to every startup we fund: that it's better, initially, to make a small number of users really love you than a large number kind of like you."

Excitement is a terrific metric.

It's possible to get people involved with a product if they're not excited about it. There's still growth involved. But the difference between that and a project people actively fall in love with is extraordinary.

Yes, making it exciting is more important than making it easy to develop for.

"Excitement" is a benefit, not a feature. This distinction from advertising is obvious, but hard to drive into engineering (even when it's me).

I was looking up information about the book Punk Marketing a few days ago, and somebody gives an anecdote about a presentation they gave where the first slide was titled "How to Market to Generation Y", and the second slide was titled "You can't.", and that was the entire presentation. And there's some truth to that. The more people advertise, the more people get bored. So excitement becomes the only thing that matters.

Until my current project I always thought that excitement was something that you simulated to get users. The guy who built and marketed Zoints, the start-up I did work for in high school, would IM me and talk about these campaigns he wanted to run on forums where Zoints employees would become forum members to talk about how much they loved the network (it was a social network for forums, essentially). And I thought, Oh, this is how you generate excitement. Then I started demoing Cirqueti to people in January, and suddenly I was getting absolutely ridiculous feedback. Things like, I'd talk to somebody about it on IM, and they would go to their college and talk to their professor or their class about it. One guy keeps bringing friends onto his IM account to ask me questions about it.

It's insane, and it's a terrific feeling, and more than that it's genuine. I love it, because it means I don't have to lie or oversell what I've got: from the initial reaction it doesn't at all look like that'll be necessary, and I can focus on just making it better. And the best part of that is it's not marketing. Like, this isn't some cynical attempt to gain users. It's much more honest, because they're doing it on their own. I've seen that with a lot of web sites, in particular Facebook, which ran no ads on competing web sites (unlike TagWorld, which people thought was a big potential competitor, and which would advertise everywhere). I love it. It shows that if you've actually made something good, then you don't have to worry about advertising and you can just be yourself and do your own thing.

'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.)

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.

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

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.

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.

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?

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.

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.

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

Daring Fireball == glaring fanboyism.

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…

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.

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.

"store" simply doesn't exist in this article

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

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact