Holding a program in one's head

>startups are the best way anyone has found to develop great new software

YC's program is 10 weeks. The time ALONE means they aren't developing great new software that other people can't make. Back to your Microsoft example, they were notorious for having people demo for them, then stealing the idea and developing it in-house. (Remember how start-ups were all scared of going into a market segment Microsoft might want?) A start-up isn't even a good way of getting an audience, which is what Reddit, YouTube, etc. were bought for, because chances are your start-up will fail. The reason start-ups collectively work is there are so many of them, a big company can just acquire the winners.

Focusing on only the hits and ignoring the misses is a hallmark of pseudoscience, so if we're going to trumpet the winners let's compare that to the vastly larger deadpool. Start-ups are 10x more effective in producing stuff that goes nowhere. Big companies are automatically better at producing stuff people use than 90% of start-ups for that reason alone.

> I'm just claiming they're better at producing new great stuff and that big companies suck at it.

I think this is a case of "the overwhelming majority of great developers do not work at YOUR company". Numbers alone mean that more great ideas will come from outside your company than from within. More new stuff will always come from everyone not at company X than at company X.

Working at Google doesn't seem to stop people, hired or acquired, from coming up with good stuff, so once again we're back to start-ups being an advertisement of who's dedicated rather than a superior development methodology. I mean there are only so many ways you can just sit there and code, there's nothing magical about doing it in a cramped apartment. And it's demonstrably worse to do it on ramen than on free gourmet health food.

The reason Joe Kraus and others romanticize it is because they were young, it was new and exciting, and they were doing it with a bunch of their friends. That's a good recipe for getting something done, but the code's going to be a mess if you're inexperienced, and worse if you're rushing to a demo. Out of large numbers of people getting something done, some of those will be a lot better than others. It's a numbers game. VCs fund, what, way less than 1%?

They aren't incapable of it, they do it too. They just have different priorities. A company's goal is to grow as large as possible. They want to shut out competition.

Both of those reasons explain why they acquire start-ups -- one, to feed the beast. Two, to stop any threat to their gluttonous expansion.

Microsoft's core is still Windows, Word, and Excel. Google's is still the search they started with when they were a start-up (every big company was once a start-up), not any of the start-ups they've since acquired. The core products pay the bills; the rest is filling up the cracks.

The numbers game is of crucial importance because large companies externalize the cost of the selection process. Google will pay a little for dedicated people and a lot for a big audience to sell ads to. Everyone's just still stuck on the old paradigm of either some time-wasting interview process ("what are you interviewing for?" "A job!" "To do what?" "I don't know exactly!") or buying a start-up with a self-selected people/problem combination that already seems to work.

> Why doesn't intense determination to develop something great qualify as a methodology?

I think we're getting a little carried away here with hyperbole. There are few "great" ones, that's not a methodology, although self-deception might qualify. Steve Jobs had an intense determination to develop something great -- the Mac. Hardly anyone falls into that category. Most start-ups now are excited kids who mainly want to make some quick bucks.

And I note the Mac was created BY a gigantic company, by someone who was already rich (and a bunch of engineers on minimum salary -- hey, it's Jobs). It's WHO, not WHERE, and I note design-by-committee-with-endless-meetings has been recognized as a mistake for a long time (Apple III).

And yes, the code does matter.

> Can you spot the contradiction?

No, it's 5 am, I'm up because my neighbor was crashing around, I don't even know what I'm writing. I seem to be talking myself into agreeing with PG.

The common theme here seems to be succinctness and efficiency in design. The Woz example is a a classic here. The design process clarity of purpose through reduction until it is as simple as you can get it has merit.

So is it the speed of iteration to reach "high efficiency design" be the goal as well?

Reading FOW, Ch12, p164 Paul Buchheit it is more like trying to fit new functionality into the search engine infrastructure, ("we only do web search"). Though to be fair pb does suggest this has changed.