Microsoft’s primary failing, Cringely says, is technical arrogance:
Some of this is native and some is a vestige of Redmond’s long association with IBM. Taking the IBM connection first, let’s look at something current Microsoft CEO Steve Ballmer said in my 1996 PBS documentary, Triumph of the Nerds:
“In IBM there’s a religion in software that says you have to count KLOCs (pronounced KAY-lock), and a KLOC is a thousand lines of code. How big a project is it? Oh, it’s sort of a 10 KLOC project. This is a 20 KLOCer. And this is 5O KLOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS/2, how much they did. How many KLOCs did you do? And we kept trying to convince them — hey, if we have — a developer’s got a good idea and he can get something done in 4 KLOCs instead of 20K-LOCs, should we make less money? Because he’s made something smaller and faster, less KLOCs. KLOCs, KLOCs, that’s the methodology. Ugh!”While Microsoft learned a lot from IBM, this whole KLOC-orientation and associated ass-backward reward scheme repulsed them because it led to bloated code. So just like a child who grows to ultimately emulate or rebel against parental examples, Microsoft shunned the KLOC and embraced the power of tight code. And though it might surprise you from looking at their current product lines, they still do.
The way a company that prides itself on tight code can build something as floppy (in every sense) as Windows Vista is because Vista is simply too big for any one Microsoft executive or engineer to understand in detail. So they embrace the idea that piling lots of chunks of tight code somehow won’t turn into a huge steaming mass of not-very-tight product. But it does.
But wait, there’s more! Somehow this mistaking fat for muscle became institutionalized at Microsoft through a unique group of people called Program Managers or PMs. This is a Microsoft invention intended to make their products more useful and elegant, yet in practice the PMs do just the opposite.
Program Managers at Microsoft are the advocates for software usability. They link (or are supposed to link) to the rest of the company development, usability and testing. They write specs and try to optimize the user experience, though with only limited success.
The bloated development, test, and PM teams across the company are a sign of Microsoft’s obsession with technology and all things technical. There aren’t nearly enough usability engineers, designers, writers, editors, and other people who worry about how usable the software actually is. In other words, like the people who run the feature teams at Apple.
A Microsoft designer once said that the biggest difference between Apple and Microsoft was that at Apple designers usually owned the product features, while at Microsoft, PMs always own the features. And most of the PMs at Microsoft are highly technical, often with computer science degrees. This is considered a good thing, by the way, but it isn’t good at all. It means the PMs tend to lean in favor of the developers just as management leans in favor of the developers, too. So in most cases where usability goes head-to-head with development, usability loses. And so do users.
The answer for Microsoft is not to blindly copy Apple because Microsoft will never BE Apple and will never have a Steve Jobs as boss. The answer is to adopt a similar product design philosophy to Apple’s with the focus squarely on usability.
This will not happen EVER with the present culture at Microsoft.