Let me start by saying I think it’s great that Mike at Mobile Jaw and Chris from GearDiary are doing this. It’s a neat idea and I’m looking forward to the results. At the same time, while I think this idea is interesting, it also has some inherent flaws. Again, I’m not saying their idea is a bad one or that the results won’t be interesting. I just feel that since our app is one of the ones being used in the experiment, and could thus be blamed if the device still crashes, that I need to say a thing or two about this idea.
So if you want to hear my take on device stability and the “No Reboot Challenge”, read on!
So the theory goes something like this:
Instability in the operating system is not a result of bad design by the OS manufacturer but rather a result of badly designed third party applications.
The goal, as I understand it, is to prove that MS gets way too much grief over the instability of its operating systems (mobile and otherwise.) I think this is true and I think proving this is a laudible goal. Unfortunately, I’m not sure that the methodolgy of the Challenge is sound. Not only might it fail to prove the point, but (and this is what worries me) it could wrongfully implicate a developer in the process.
Impossible to Prove
Unfortunately, it will be impossible to pinpoint the source of instability, even with very few applications installed. A flaw in the OS might only rear its ugly head when an application is installed, not due to any failure on the part of the developer. It could be that the flaw remains hidden until an app is run.
It’s like building a bridge and watching it collapse when the first car goes across. Do you blame the car or its driver for driving across the bridge improperly? I mean, the bridge was working fine until the first car drove over it so it must be the car’s fault, right?
It Isn’t Easy to Screw Up the OS
Some will surely disagree, but in my experience it isn’t easy to botch up an operating system accidentally. You’ve got to work really hard to mess up your software so much that the entire OS suffers. Crash your own application? Sure. But screwing up the whole OS is something else entirely.
And let’s be frank about this. The times I’ve seen our applications cause what appeared to be a wide-spread issue (and these were VERY rare and never made it out the door), in the end we discovered that some aspect of the OS was not working as advertised. Perhaps it was a custom method the device had for handling images that failed, an out-dated library, or a missing piece the hardware manufacturer didn’t think was important and cut. In the end, we wrote work arounds to avoid problems with the OS. Had we released the software without addressing this, to anyone on the outside it might have looked like “we broke the OS”, but that simply wasn’t the case.
Failure to Lock-Up the Dogs
But let’s say that some application really IS screwing up the OS. Shouldn’t there be some sort of “police officer” built in to protect the user from this sort of thing? Isn’t it the responsibility of the OS manufacturer to provide customers with a stable user experience? If they are giving applications access to portions of the OS that can cause the entire system to perform badly, is that really the sign of a good OS? I’m all for freedom and flexibility for developers, but someone has to be the boss and say “You can ride in the car but you can’t drive it!”
So there you have it folks…
…my take on the No Reboot Challenge. It’s a cool idea and I hope something cool comes of it, but I’m very concerned about the conclusions folks may come to if things go south.