Google Executive Chairman, Eric Schmidt, while at the Mobile World Congress held in Barcelona a couple weeks ago, used his keynote address to discuss the future of the Android mobile operating system. Among the points he addressed was the naming convention for the next version of the OS, quipping that version 2.3 for smartphones, code-named “Gingerbread,” would be merged with the tablet optimized version 3.0, code-named “Honeycomb.” ReadWriteWeb reported that while Schmidt would not confirm reports that the name of the resulting OS would be “Ice Cream,” he did say “the follow-up release will start with an "I" and will be named after a dessert.”
“Ice Cream,” huh? Why not “Pie,” “Brownie” or something more calorie conscious like “Fruit Salad?”
It seems that Google has fallen into the trap of believing its own press clippings – the positive ones, at least – because they seem more concerned with finding a cute and catchy code name for their operating systems than they are about the quality of those same systems. That has been the history, to date, of Google’s mobile operating systems as one flaw after another has been uncovered and always after the system has been rolled out and installed by the consumer. Android has been so bereft with security flaws that no less than Tom Gillis, general manager of Cisco’s Security Technology business, has said he’s “rooting for Android” to gain a larger share of the market because all the security holes will mean more business for Cisco.
One of the more recent security holes was a data-leak vulnerability that was traced to an earlier iteration of Google’s mobile operating system called Froyo. And that’s what makes Google’s almost blasé attitude toward the quality of its operating system so maddening; not only do they seem more concerned about what they’re going to call it, they actually KNEW there was a problem, FAILED to fix it and then BUILT on top of it! If the ancient Egyptians used the same methodology, the pyramids would today be nothing but rubble and dust.
Had Google bothered to perform automated analysis and measurement of their software before they declared it “ready for prime time,” they would have discovered the old security issue and been able to patch it before it became a new security issue. Moving forward, Google really needs to go beyond testing, which cannot sufficiently assess the structural quality of the entire system and identify those areas that could lead to problems post-deployment.
CAST measures structural quality using hundreds of metrics that capture the design and implementation issues within complex systems; particularly important as more and more application software is built upon layers of code that may already be bringing flaws to the party. By quantifying structural quality in terms of Technical Debt – the cost of fixing the structural quality problems that cause severe business disruptions – CAST not only identifies the IT issue, but makes the business case for its resolution.
Moving forward, Google should keep an eye on its Technical Debt, lest its old flaws lead to new flaws that result in the melting of their “Ice Cream.”