Microsoft Bricks Windows 7 Phones
The above headline should never need to be written. A company should never "brick" or render any product that a customer paid for useless. The company should replace the product if this happens accidentally and pay a fine for seriously inconveniencing the customer.
And exactly what mechanism is in the phone that "bricks" it and renders it useless anyway?
Much of the updating problems stem from the halcyon days of AOL, the company that perfected the slipstream update. Back in the 1980s and 90s, when AOL pretty much owned the online segment of the industry, the system would tell you that it needed to make an update when you tried to log off. For the next 15 minutes, AOL would be plugging in all sorts of new code.
I found that this process worked well. When users were confronted with other systems that wanted to upgrade in later years, reluctance to approve the process set in, especially when it came to Microsoft Windows and its constant need to upgrade on what became "patch Tuesday." This was the result of various upgrades failing for various reasons. It was a little more complicated than fixing AOL.
Apple has done a reasonable job of updating Mac software on the fly. It held an impressive record of quality upgrades with minimal failures. More impressive, at least to me, is that Apple managed to incorporate performance upgrades, so the machine often improved in performance after an upgrade. Windows machines, on the other hand, seemed to continually degrade with each update, running slower and slower over time.
The knowledgeable user generally does not like the auto-upgrade idea. It just seems risky under most circumstances. This is proven every so often when an upgrade fails and has to be fixed in a panic by the company.
The most recent upgrade with the Win Phone 7 is a perfect example. We hear that the process failed on 1 out of 10 phones. This is probably a low estimate, but a 10 percent failure rate is still ridiculous, especially if some phones then became unusable.
In the first place, there's something wrong if these software systems are so poorly designed from the outset that they need weekly (in Windows case) or even monthly updates to "fix" problems with the code. I understand that weird things happen in the field, and it's hard to predict that dialing 0 on the phone while in a call-waiting state while surfing a flash-enabled site from an .org domain might trigger a bug. You still have to wonder how the code was structured in the first place.
With game software, for example, each developer has a set of tools that they use over time to develop the next generation of product. The longer they are in business the more elaborate and useful the tools become until some of the most amazing games in history emerge. Many of which are bug free.
Why doesn't this happen with operating systems? The things evolve in complexity like games, but devolve in stability unlike games. What's the difference? What changed? I've been told by more than a few people that the Windows code base is evolved but nobody that's still at Microsoft knows anything about how it works. It's become a black box. Maybe that explains it, if it's true.
The Apple OS, on the other hand, has a UNIX kernel and is newer. The Apple iPhone iOS is newer still. That would make me think that the Windows Phone 7 OS is new too and not subject to all the historic problems of Microsoft's spaghetti code.
I assumed too much. Phone 7 appears to be a gussied up version of Windows CE, which means it's a lot of old spaghetti code that has been made to look good. This means risky patches. If the upgrade fiasco is any indication, I suspect there will be more of the same glitches in the future. I wish users luck if Microsoft begins patching like crazy, which I suspect it will.
0 Responses to "Microsoft Bricks Windows 7 Phones"
Post a Comment