Friday, July 16, 2004

Performance Tuning MSFT.exe (or, How to Save Microsoft $1,000,000,000 Now)

One of the core skills a developer has to excel at is performance tuning. You get your feature working correctly and then you go in and analyze where the code is actually spending a good bit of its time. You get a prioritized list of areas to improve, starting with the most obvious opportunities for maximum payback.

So, two of the big mistakes you can make are:

  1. Over-optimizing new code before you actually have a chance to measure it. You're most likely making it way more complicated and bug-ridden and you can be completely wrong about where your code spends its time.
  2. Choosing to invest a large amount of effort optimizing existing code that is way down on the list of where you're spending time.

Both problems are pretty much the same: you're expending great effort that should rather be focused elsewhere to give you far more end-result benefits.

Now, when it comes to tuning MSFT.exe you'd think it would make sense for us to take a similar approach: analyze where the big expenditures are and go after those areas first. So, say you want to cut back, oh,$1,000,000,000. Where'd be a good place to start?

$250,000 / year for towels in the locker-rooms? Okay, 0.025% down, $999,750,000 to go (and that's going to be a long drinking song).

Okay, no. If I my dev team was told it had to cut 10 seconds from a module's boot time and I came forward with 2.5 milliseconds I'd be spanked for wasting everyone's time just to listen to my dumb ass. And folks would seriously, seriously wonder about how in the world I got hired.

No, my team would be looking for big, bold savings that represent making some hard decisions.

Hard decisions. Like downsizing. Layoffs. Good attrition. Bad attrition. Pink slips.

Let's say Microsoft can indeed reduce its workforce by 10%. That'd be about 5,500 flesh-and-blood individuals. We easily have that many employees we can do without. You figure each employee represents $200,000 to $300,000 cost to Microsoft each year (salary, benefits, equipment, etc etc). So, by attrition and layoff, a 10% reduction right there would save Microsoft anywhere from $1,100,000,000 to $1,650,000,000.

And this is the gift that keeps giving to the bottom line.

And would the financial world freak-out and react poorly to a smaller Microsoft? I don't think so. This company doubled in size during the height of the unsustainable Internet boom. But it has not receded to match accordingly. We struggle to keep balance and we're staggering under the load of too many employees. We should endeavor to under-go an immediate (one year) reduction by 10%. Then two more reductions within the next five years.

And you damn well better believe that a 10% reduction would bring exceeding clarity to the minds of those full-time Microsoft employees deciding what to focus their group's efforts on to add to the Microsoft bottom-line.

Where to start? MSFT.exe performance results are in the latest SEC filing (start at ). Check out the annual report. Fourth quarter / fiscal-year results are coming July 22nd - get ready for that. Take a moment to do your own analysis. To me: embedded devices: gone! MBS: profitable in a year or gone! And dear, sweet XBox? If its vision of ensconcing Microsoft as a home-entertainment platform is truly solid, it should be spun off into its own royalty paying company. Other ideas?

1 comment:

Anonymous said...

How very, very true. The complication that I see is that the people we really need to loose are most often on the dev/test manager or gpm level. People who have no longer any sort of connection with the actual job their teams are supposed to do and attempt to further their careers by inventing costly new processes, make bold decisions (we need to take _this_ direction. Why? Because it's the right thing! (Thanks for elaborating the reasoning)). We need to loose architects and leads with no technical design skills who still get to determine the guidelines and framework in which ICs more qualified than those are forced to code. And, first and foremost, we need to start focussing on the immediate customer benefit, instead of the great 5-year plan.