If this were another TransMeta, I'd agree, but the situation is quite different, because Intel is very early in their learning curve on graphics, and nVidia is quite far along in their learning curve on graphics and high-performance computing. They actually have a decent shot at competing with Intel in the low end of the desktop market by making up with the GPU what they end up lacking in the CPU.
The instruction decoders on x86 processors consume a lot of silicon. x86's instruction retirement also imposes additional overhead due to book-keeping on the scheduler. Eliminating the x87 stack-based FPU is been a gradual process involving an evolving SIMD instruction set that started as a hack.
In reality, resources trumps ISA. x86 has the advantage of hand-optimized logic combined with the best high-performance VLSI manufacturing in the industry.
In spite of that, Itanium blows the doors off of every x86 processor built on the same fabrication technology -- notice that so far, the Itanium and x86 contemporaries are built on fab processes that have been two generations apart, with the high-volume part using the newest process.
That depends on the market, I think. AFAIK most of the dissatisfaction with Atom is due to its power consumption rather than its performance, so an ARM with comparable computing power and lower power consumption would be quite satisfactory for most users when teamed up with a solid GPU.
No, he isn't. Tools need to be a high priority, or else they end up being crap. Amazon, Disney, Northrup Grumman, SAIC... all of the big companies I've worked for had the same problem: their tools were terrible.
At most of them it just meant that HR ended up wasting time dealing with crappy tools, which is no big loss, since HR is a usually a waste of oxygen anyway. At Disney and Amazon, it meant that the people producing consumer-facing content wasted a lot of time fighting the tools that were supposed to enable their jobs, and a lot of developers had to waste a lot of time supporting the tools that weren't doing their job.
For example, just two and a half years ago, one of the buyers at Amazon showed me how she set up the relationships so that when you look at an iPod, you get a collection of compatible accessories. She had to create relationships for EVERY permutation between each accessory and for each accessory to the iPod. By hand. In a spreadsheet (Excel, I think.) Then she uploaded it to the site, and every once in a while a relationship would mysteriously fail, because of another relationship managed in another tool that she had no access to conflicted with it.
There is actually a problem when organizations are focusing too much on tools.
In order to efficiently address a disruptive innovation, a corporations need to change their processes and since tools are connected to processes, these good tools make that change even harder.
Yes, it good to have good tools for developing the current product, but organization needs to be ready to eliminate internal tools without hesitations.
I agree -- becoming too attached to existing tools is a major drag industry-wide. Even if it's well-designed in the beginning, which from what I've seen is extremely rare, it tends to devolve into a mess given enough time.
To get maximal value out of the tools, everyone has to be willing to toss them when they start to becoming a big enough impediment. (Deciding on that isn't always easy, of course.)
My experience at amazon would fail the Joel Spolsky test:
Do you use source control? yes
Can you make a build in one step? almost
Do you make daily builds? I think so
Do you have a bug database? yes
Do you fix bugs before writing new code? not usually
Do you have an up-to-date schedule? Hard to tell
Do you have a spec? a vague one
Do programmers have quiet working conditions? no
Do you use the best tools money can buy? not even close
Do you have testers? users
Do new candidates write code during their interview? yes
Do you do hallway usability testing? no
The computers that Amazon provided were so old that they weren't even in current production (I checked the serial number for the laptop I had there, and it was according to Dell 3 years old -- and low-end even when it was new)
One must take under consideration the definition of "smart" first.
I had a co-worker who had memorized a raftload of facts without actually understanding many of them. She frequently mis-diagnosed problems with customer computers because although she had a huge list of facts in her head, she couldn't think her way through them to make sense of what was really going on.
Due to her ability to spew facts on demand however, the management thought she was exceptionally smart, even though she couldn't actually figure anything out for herself.
The company's hierarchy reinforced this sort of thing, because the "engineering" team was a bunch of college dropouts who didn't have the faintest idea as to how things like UNIX networking worked. They said that total memory = physical + virtual, so my attempts to explain that UNIX doesn't work like that went unheard, and customer machines continued to suffer because they didn't have enough memory to serve their buyers' needs.
The last I heard the company had something like a 4% customer satisfaction rate.
While I agree your sentiment that degrees and IQ have next to nothing to do with whether or not someone is actually smart, have a look at current culture and at corporate america.
At amazon, everyone was obsessed with how "smart" amazon employees were, and yet the place was a showcase of terrible engineering -- rife with accidental complexity and tight coupling that spanned not just systems within a group, but across entire divisions -- and some what I read in this article I saw there first-hand. The management complained constantly about how bad our tools were, yet the people that they promoted and took care of were the ones that designed and implemented those same tools.
A great many managers haven't the faintest idea as to how to determine what constitutes a "smart" employee, so they zero in on things like degrees and number of hours worked because they don't have any rational standard for identifying the good ones from the bad, so the guy with the degree who's working 80 hours a week is obviously the best guy on the team! Look how hard he's working! He must be REALLY smart!
"Also, the article seems to conflate having an MBA with being smart. I wonder if Gladwell has ever thought that the reason Southwest has a vastly more efficient organization than its competitors is because it has a bunch of smart people who figure out how to do things more efficiently. People so smart in fact that they realize people on the ground can make much more informed decisions than people in a boardroom."
I think that was precisely his point. Enron used MBAs as a proxy for "smartness" and turned out to be a spectacular disaster. Southwest doesn't, and is one of the few US-based airlines that isn't relying on the US government to keep it alive.
Could it be that once you reach a certain level of size in any organization bureaucracy and complexity turns up? The reason why Amazon might have "terrible engineering" while the sleekest app startup doesn't is because Amazon is really, really big.
Look I understand degrees and IQ really don't mean much by themselves. Most of my friends attend "elite" colleges (as society deems it). Some are brilliant. Some aren't. However, the numbers show that "smartness" and particularly an "obsession" with smartness matters. Amazon is really successful. Google is really successful. D.E. Shaw is notoriously successful. Facebook is successful. Teach for America is super successful. The defining theme to all of these organizations is a focus on hiring the best talent possible. And often times the best talent happens to be at those top schools.
Think of the timeline of hiring. These companies often target people in the 22-27 age bracket. That is just 4 to 9 years away from their high school when college decisions were made. Work ethic, ambition, and a determination to get things done is pretty damn autocorrelating in its nature. Someone mentioned how PG noted in an essay that he was underwhelmed by MIT, Harvard, Stanford kids. But look at the YC startups. The number of startups funded by YC by alumni from MIT, CMU, Stanford is far more than what it would be if there was no correlation-causation.
I think drawing broad conclusion from a criminal enterprise like Enron is a poor way of doing things. Just because Enron touted their smartness and failed doesn't mean that is the norm. On a large enough sample set, I will still bet you that the McKinsey conclusion is right in that "talent" and the drive to get the top talent is still a big part of the most successful organizations.
"Could it be that once you reach a certain level of size in any organization bureaucracy and complexity turns up?"
I would tend to agree with that, although I've seen startups run by bad managers install a pointlessly complex hierarchy for no reason other than that companies have hierarchies.
"The reason why Amazon might have "terrible engineering" while the sleekest app startup doesn't is because Amazon is really, really big."
No. Their abysmal engineering is by far the worst I've ever seen... well, not by far, what I ran into at Disney gave Amazon a run for its idiocy. The reason for the terrible engineering is that amazon is a Gen-Y shop. The company is notorious for abusing employees, and very clearly shows preferential treatment to interns rather than seniors. They have a lot of trouble hiring experienced engineers, and since everything they do is an emergency, they put however they can on the job... in other words, most of Amazon's mission critical software was designed and implemented by people who either just graduated from college, or hadn't yet (interns).
And then they hire seniors to "fix" it... the culture is such that they think "smart" is the ticket, and don't value the wisdom and knowledge that come with experience.
Now count the number of successful companies to the number that aren't. And take into account the number of unsuccessful projects compared to the number of successful ones, even at successful companies. What I suspect that you'll find is that in most companies, even successful ones, the primary reason that projects "succeed" is that the management changes its definition of "success" in order to avoid taking blame for mis-managing a project to its demise.
Almost every flight during peak travel periods is oversold, which means that the airlines are selling more seats than they have (which sounds like fraud, since if you end up in an oversold flight and no one cancels, they ask the PASSENGERS to make the sacrifice, even though the reality is that the airline sold something that they no longer had)... so there was almost certainly someone else who got his seat.
