Subscribe to EDN

The Microsoft/T-Mobile fiasco

October 13, 2009

I talked a couple of weeks ago about how it is necessary to be brutal and cull the managers of internal products in an acquisition otherwise the management of the joint product roadmap would become completely dysfunctional.

Unless you’ve been living under a rock, you probably are aware that Microsoft had a catastrophic failure of their back-end server systems that support T-mobile’s Sidekick phones, losing most user’s data completely without any backup. There are various rumors around about how that happened, the most complete one is here. At root, part of the problem is having two internal groups, one acquired, one with a special conduit to senior management, doing roughly the same thing. The one without the conduit to senior management knew what it was doing; the other not so much. They didn’t cull (in fact they did the opposite, they created a new competing group).

Now, a new source has stepped forward to elaborate on why Microsoft’s Danger acquisition failed so dramatically. This source, intimately involved in the core engineering circle of Microsoft’s Pink Project, outlined that Pink wasn’t simply the acquired Danger group, but existed prior to the acquisition. While the Pink group operated within Microsoft independently of both Windows Mobile and Zune, this source claims that “Pink was in fact a Zune-phone,” in that “Pink was a third group tasked with taking Zune software and making it a phone.”
 
The pre-Danger Pink group was characterized as “A huge source of trouble,” with the source explaining that “the Redmond-based Pink designers brooked no feedback and won all appeals to higher management (presumably by leveraging face-time).” Pink was given Carte Blanche to assemble a team and get started, but external constraints prevented Danger from simply growing into the Pink Project within Microsoft.

This is the most extreme example of how catastrophically things can go wrong when the management of acquisitions is not clean. You need your best people working on the most important products as quickly as possible and, like in a game of football, you want to block all the political hurdles so that they run to the end zone as fast as possible.

The whole story will probably come out gradually. Sidekick is much more dependent on the servers than iPhone since it can’t synchronize to your laptop and the designers of Sidekick made the reasonable decision that they wouldn’t try too hard to protect your data on the phone: after a major crash they simple cold-boot and reload the data from the cloud.

There seem to be rumors of sabotage, which become more likely every day that passes without some person from Microsoft explaining how it was due to a lightning strike on the datacenter, or a coincidental failure of 3 things or whatever the fundamental technical error was. The idea that a hardware upgrade went wrong and that a savvy IT group would undertake such a thing without backing everything up doesn’t pass the smell test to me.

Posted by Paul McLellan on October 13, 2009 | Comments (6)

October 15, 2009
In response to: The Microsoft/T-Mobile fiasco
SteveM commented:

It's a lesson for any engineer. Back-ups and reliability are critical system features. Too often back-up systems are assigned to the most junior programmer and are not stress tested thoroughly. It takes a keen eye to spot critical system failure modes and to design a back-up system that is triple safe. The best thing Microsoft can do is have a 'public' learning so we can all move forward and get to a better technology level.


October 15, 2009
In response to: The Microsoft/T-Mobile fiasco
xxx commented:

Microsoft could care less all that matters is the bottom Line. Vista,this boondoggle. Gates may be giving away $ in a way that would make Mother Teresa cry years of happiness . BUT he could give a crap about YOU . How much do you think this latest of the long line of gaffs cost the people ? This is not programming failure it is a rookie mistake. No Back up PLEASE


October 15, 2009
In response to: The Microsoft/T-Mobile fiasco
midlevel commented:

Microsoft does not write code programmers do. Good programmers write good code bad ones write bad code. Processes do provide safety net against bad code but ultimately more complicated software will have more bugs. And EDA industry as a whole has far more bugs than general software.


October 14, 2009
In response to: The Microsoft/T-Mobile fiasco
desert rat commented:

I agree with Payne. My greatest fear is that I will one day have to synchrinize my pacemaker (made with Intel chips) over a phone line (run by Qwest) through a telecom switch (built by Nortel) using software written by Microsoft. I'm a gonner if that ever happens...


October 14, 2009
In response to: The Microsoft/T-Mobile fiasco
Bad Dog commented:

If you have BMW iDrive... you have microsoft code in your car. If you have Ford's sync... you have microsoft code in your car.. Better get some walking shoes..


October 13, 2009
In response to: The Microsoft/T-Mobile fiasco
Daniel Payne commented:

If Microsoft were a start-up company they would simply be out of business with a gaffe like this one. The day that there is one line of Microsoft code in a car, plane or train is the day I start walking to work.

POST A COMMENT
Display Name
captcha

Before submitting this form, please type the characters displayed above. Note the letters are case sensitive:

Advertisement
Advertisement
Advertisement
About EDN   |   Site Map   |   Contact Us   |   Subscription   |   RSS
© 2012 UBM Electronics. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other UBM Canon sites

UBM Canon | Design News | Test & Measurement World | Packaging Digest | EDN | Qmed | Pharmalive | Appliance Magazine | Plastics Today | Powder Bulk Solids | Canon Trade Shows