At a training session I recently attended, a presenter mentioned that his cell phone crashes whenever he runs a simple MIDlet that he wrote. While it may have been inevitable that poor-quality environments would make it onto J2ME platforms, it's still distressing to see some J2ME development proceeding down the trail blazed by the megacorp in Redmond.

Now I am not one of those who despise Microsoft. Microsoft is not inherently evil, and both good and bad have come out of it, as is true of just about any corporate entity. But I do feel that Microsoft's sins have been egregious in the area of software quality, and I fear that it has inured us to accept software of far lesser quality than we should accept.

When your desktop PC offers up the blue screen of death, you may be annoyed and curse the denizens of Redmond, but most people have come to accept occasional freezes and splats as one of the costs of computing (or, at least, the cost of computing with Windows). But there's no reason we should carry those diminished expectations to mobile devices.

Because the primary purpose of PCs is computing, it may be easy to rationalize software failures as the price you pay, but the primary purpose of cell phones is communication. For this reason - or from a different perspective, because anything that impedes making and receiving calls reduces revenue - most cell phone manufacturers and network providers have historically been very restrictive about what, if any, third-party software they allow on their handsets. If customers can't make or receive calls, they'll be more inclined to switch carriers, and they'll rarely make a distinction as to whether it was the hardware, the software, or the network that was at fault.

This mentality contrasts sharply with that of the other major platform for J2ME applications, PDAs, which have from the beginning been first and foremost about applications. Since the early Palm Pilots (and their precursors), the modus vivendi with PDAs has been to download applications; so where cell phones restricted customer deviation from a defined configuration, PDAs embraced it. Consequently, PDA manufacturers and users may accept the occasional crash, much like they do on PCs, as a risk worth taking. To what degree are we willing to trade off the reliability of cell phones for the convenience that downloadable applications add?

Shouldn't we first ask whether we need to make significant trade offs? Is it not feasible to architect the KVM to be, if not bulletproof, at least robust enough to prevent all but the most onerous and insidious programming errors from significantly compromising the reliability of the platform? Or is it that we could, but it's not considered cost-effective to invest the extra effort to do so? Or is it time-to-market that trumps the delivery of quality software?

Consider some of the vulnerabilities that poor quality software could expose us to as cell phones become more powerful. You'll have financial and other personal information on your smart phone, but will it have enough computing capability to support virus checker, or firewall software powerful enough to thwart sophisticated attacks? Your cell phone's mobility combined with Bluetooth and WiFi capabilities will allow it to be more promiscuous than a desktop or a less-mobile laptop, joining and parting ways with numerous hotspots as you travel around. Does ubiquitous computing mean ubiquitous targets for compromised security?

Many efforts are afoot to address these concerns, and the walled-garden security model of the KVM is a good foundation. But as with building a house, a great blueprint counts for little if the construction is shoddy. What can we do? As developers we can promote high quality in the software we write, and provide informed voices in discussions of the issues and in the development of specifications. As consumers we can vote with our pocketbook, eschewing OEMs and network providers who offer substandard services. But ultimately it's the marketplace that will determine the quality provided.