Hacker News Reader

I'm not so sure you're interpreting that quote correctly. The Apollo space program didn't really start out with the declaration that "we're going to put a man on the moon", it started out with a bunch of rocket scientists in Germany trying to lob bombs onto London. And before that, of course, there were even simpler attempts to build rocket-like devices.

Then, looking at the Apollo program itself, they didn't send someone straight to the moon. There were many simpler missions before they finally culminated in the moon landings.

The point of that quote is that even something so monumentally complex as the Apollo space program started with something simpler that worked, and evolved up from there.

I would suggest that revolutionary start-ups are precisely the ones that need to start simple, because it's not quite clear where they're going, so they need to figure out the simplest thing that works before making it more complex. Evolutionary start-ups, on the other hand, can probably afford to stand on the shoulders of previous attempts and start with something a little more complex, because they already know what works - but even that is risky.

No, the Apllo program didn't start with rocks and sticks and built from there: If you go back far enough you can probably assert that everything derives from fire. but I think that's kind of missing the point.

Of course they did tests. Of course they fired small rockets in the Mohave desert. But they did it all with one simple goal in mind: Putting a man on the moon. They knew exactly where they were going, and everything they did was just preparations for that. They knew that their final, and only, test would come the day they launched. The difference between evolution and revolution as I described it above lies primarily in whether you know the goal.

It's definitely possible to take the evolution route (I don't quite agree that there's a clear dichotomy between revolution and evolution) and have a goal in mind. I'm sure Steve Jobs had already envisioned the App Store when he was working on iPhone 1.0. The difference between complex and simple lies in focus. The reason it's not possible to build complex systems from scratch is that you just can't focus on so many different parts/components and integrate them together as well. Apple builds successful products because they focus on a few things rather than do everything all at once.

As for your other point, I believe Gall's law (your quoted bit) holds true for all cases but the other rule I added about each intermediate step being useful might only be true for some cases (perhaps, more for user-facing products).

You're right that the blogpost might only pertain to "evolutionary products and startups". I wrote it with software in mind but my guess is that it's also mostly true for other kinds of things. I need to think further about them.

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.

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

"You have an implicit assumption that rapid iteration means poor quality control. It doesn't have to."

I would actually go a step farther and assert that strong quality control facilitates rapid iteration. My 15 years of experience in software bears this out -- the (extremely rare) projects with quality control were far smoother than the ones without. In ones without solid QA, the software become so convoluted and messy that rapid iterations became entirely infeasible. There was no way to change the software without re-writing large chunks of it, or putting in a large collection of hacks that broke as much as they fixed.

Maybe we have different interpetations of "revolutionary." I see something like the transistor a revolutionary discovery/invention. It rests on some pretty complex physics, but is a small and fairly straightforward concept to explain. Yet it has changed electronics and the way we live forever.

The same could be told of the discovery of DNA's structure. Everyone can imagine the double helix, but it has spawned an entire industy in bio-engineering.

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

That's not true at all. Complexity has absolutely nothing to do with whether or not a product is revolutionary or evolutionary, that's just from the idea(s) behind it.

The Apollo program DID launch early and often. In reality, the R&D behind it began long before we decided to send people to the moon.