I've heard that Ballmer's resignation was a surprise internally. Speculation is that "something must have happened," possibly large shareholders gearing up for some kind of fight. The Surface RT thing cost MS about $40B in market share, so upset investors makes sense.
My /guess/ is that Ballmer was driven out by the RT mess, combined with the Win8 mess, combined with a realization that MS isn't being directed very well from a technical standpoint. What will make Windows 9 a success? I just don't see it happening.
This is going to sound crazy, but I think the problems at MS can be summarized in a few short bullet points:
1. The review system. This has already been talked to death, but it's at the core of /why/ MS does the things it does, and it's got to be fixed. It will take time, and it will be painful, but if they don't address this then MS isn't going to be around in 20 years, maybe even 10.
2. Getting rid of toxic people. Less discussed, but canning a largish number of bad personalities would help a lot. (I was engineering ways around some real prizes -- if a guy's an incompetent jerk, it turns out you can architect him into being inconsequential!)
3. The build system. Hoo boy.
The way that Microsoft builds software hasn't been discussed much, but it's worth an in-depth look because if you can't build software effectively then you can't make it good. You can get fit and polish on a product /far/ more easily if you can turn it around and get rapid feedback, and Microsoft's process here is /broken/.
Ballmer has said, "Windows on everything," and right now if you're working on a system of any complexity, if it's not using Windows or one of its embedded variants you're going to get into trouble. Windows is the only politically safe choice. "Not Windows" and "Not able to run office" has killed a lot of perfectly reasonable products.
Building big systems at MS is a many hours-long process. If you built every component on a typical developer-class workstation it would take a couple of days (36 hours on my last attempt), assuming you've checked out the code at a time when it will build without errors. Good luck with that.
So you build just the pieces you need, but on a real project even that will take hours (3-4 hours in my experience). So you start to cowboy things and try to patch up a way to get your builds down to a tolerable few minutes. But the shortcuts you take make build breaks more likely when you check in, so here's what you do:
a) Find a working build. This might take a day or three, depending on whether things are broken or not.
b) Once you get that, stick with it as long as you can. Get your shit working.
c) When it comes time to check in, either
- sync minimally, try to ensure that things aren't dramatically busted, and submit, or
- get a working build (back to (a) and maybe several days of hunting for a window), merge, and submit. Congratulations, you're one of the good guys.
- Or check in blindly. That's right, some people don't even bother doing due diligence. Some groups have check-in barriers (required reviews, or build bots), but this adds additional hours even for simple changes.
The more dependencies you have, the worse things are; things are more likely to be broken, your own builds can take days, and every submit runs a high chance of breaking someone else. Staging a deliberate and breaking change across the dozens of depots is very difficult and time consuming.
If your organization's development pace is glacial, /of course/ you are going to be deferring bugs and avoiding changes to huge and mysterious bits of software, because fixing stuff means breaks at many levels, and tons of lost time.
MS needs to invest heavily, and I mean HEAVILY, in ways to make their engineering staff more productive. None of this false pride about how long it takes to compile umpteen million lines of code. The fact is, engineering is at the coal face using picks and shovels and breathing bad air, and Ballmer doesn't appreciate how having a frustrating, slow, error-prone and politicized build process has affected his ability to ship good products.
I'd say: Erect server farms so that every engineer can get a full build in five minutes. Microsoft has smart people; I think they could do it, though it would involve throwing away a bunch of politically sensitive components. The model that has every developer attempt to build Windows on his own workstation should be utterly tossed.
It's hard to see Microsoft recovering from this. You've outlined a set of problems that boil down to politics, and they inherently need political solutions this side of Chapter 11 or 7.
More specifically, Microsoft is a company selling products with a foundational technical component, but its run almost exclusively on political rather than technical merit.
I've said about much of the company's history that one of its secrets of success was writing software that basically worked (i.e. doesn't GP/segfault) ... I wonder how close the company is to losing that more and more often. A problem with e.g. the KIN, although it was rumored that was pushed to market simply to satisfy a contractual obligation to Verizon Wireless.
Which brings a final point: the politics is directed almost entirely inwards. Microsoft's long history of screwing partners is not doing it well in the devices and services world it's trying to compete in.
I suppose it could retreat to Windows on the desktop and servers/Office/enterprise in general and play that game out (a bit like IBM), but I suspect would take a massive political effort to constrain the company's ambitions prior to it getting a lot more thoroughly crushed in the marketplace.
If they really don't have centralized build farms they're NUTS. Seriously? It isn't just buying you horsepower, either; it's buying you an identical build environment every time, done right at least. It guarantees there isn't some weirdness about a developer's workstation where it builds right there and not anywhere else.
I've heard that Ballmer's resignation was a surprise internally. Speculation is that "something must have happened," possibly large shareholders gearing up for some kind of fight. The Surface RT thing cost MS about $40B in market share, so upset investors makes sense.
My /guess/ is that Ballmer was driven out by the RT mess, combined with the Win8 mess, combined with a realization that MS isn't being directed very well from a technical standpoint. What will make Windows 9 a success? I just don't see it happening.
This is going to sound crazy, but I think the problems at MS can be summarized in a few short bullet points:
1. The review system. This has already been talked to death, but it's at the core of /why/ MS does the things it does, and it's got to be fixed. It will take time, and it will be painful, but if they don't address this then MS isn't going to be around in 20 years, maybe even 10.
2. Getting rid of toxic people. Less discussed, but canning a largish number of bad personalities would help a lot. (I was engineering ways around some real prizes -- if a guy's an incompetent jerk, it turns out you can architect him into being inconsequential!)
3. The build system. Hoo boy.
The way that Microsoft builds software hasn't been discussed much, but it's worth an in-depth look because if you can't build software effectively then you can't make it good. You can get fit and polish on a product /far/ more easily if you can turn it around and get rapid feedback, and Microsoft's process here is /broken/.
Ballmer has said, "Windows on everything," and right now if you're working on a system of any complexity, if it's not using Windows or one of its embedded variants you're going to get into trouble. Windows is the only politically safe choice. "Not Windows" and "Not able to run office" has killed a lot of perfectly reasonable products.
Building big systems at MS is a many hours-long process. If you built every component on a typical developer-class workstation it would take a couple of days (36 hours on my last attempt), assuming you've checked out the code at a time when it will build without errors. Good luck with that.
So you build just the pieces you need, but on a real project even that will take hours (3-4 hours in my experience). So you start to cowboy things and try to patch up a way to get your builds down to a tolerable few minutes. But the shortcuts you take make build breaks more likely when you check in, so here's what you do:
a) Find a working build. This might take a day or three, depending on whether things are broken or not.
b) Once you get that, stick with it as long as you can. Get your shit working.
c) When it comes time to check in, either
- sync minimally, try to ensure that things aren't dramatically busted, and submit, or
- get a working build (back to (a) and maybe several days of hunting for a window), merge, and submit. Congratulations, you're one of the good guys.
- Or check in blindly. That's right, some people don't even bother doing due diligence. Some groups have check-in barriers (required reviews, or build bots), but this adds additional hours even for simple changes.
The more dependencies you have, the worse things are; things are more likely to be broken, your own builds can take days, and every submit runs a high chance of breaking someone else. Staging a deliberate and breaking change across the dozens of depots is very difficult and time consuming.
If your organization's development pace is glacial, /of course/ you are going to be deferring bugs and avoiding changes to huge and mysterious bits of software, because fixing stuff means breaks at many levels, and tons of lost time.
MS needs to invest heavily, and I mean HEAVILY, in ways to make their engineering staff more productive. None of this false pride about how long it takes to compile umpteen million lines of code. The fact is, engineering is at the coal face using picks and shovels and breathing bad air, and Ballmer doesn't appreciate how having a frustrating, slow, error-prone and politicized build process has affected his ability to ship good products.
I'd say: Erect server farms so that every engineer can get a full build in five minutes. Microsoft has smart people; I think they could do it, though it would involve throwing away a bunch of politically sensitive components. The model that has every developer attempt to build Windows on his own workstation should be utterly tossed.