Perfect software
Our customers want the code to be perfect. But they've learned to manage in a world full of electronic gadgets that sometimes behave oddly. Even a member of Garrison Keillor's Professional Organization of English Majors (POEM) knows to cycle power or yank the batteries for ten seconds when the widget freaks out. Our imperfect code has taught the world the meaning of the word "reboot." I well remember when only techies knew what that meant.
While I don't know if all of Micrium's code is perfect, its quality far exceeds the vast majority of programs I've examined. It's all surely PDP: Pretty Darn Perfect. Micrium is not alone; Green Hills achieved EAL6+ certification on a version of their RTOS, so that code, too, must be PDP. Plenty of other embedded applications meet the PDP level as well.
In fact, according to data collected by Capers Jones that he shared with me, software in general has a defect removal efficiency (the percentage of bugs removed prior to shipping) of 87%. Firmware scores a hugely better 94%. We embedded people do an amazingly good job.
But the irony is that software is topsy-turvy. Unlike physical things it is theoretically perfectible, but also unlike physical things a single error can wreak havoc. A mechanical engineer can beef up a beam to add margin; EEs use fuses and heavier wire than needed to deal with unexpected stresses. The beam may bend without breaking; the wire might get hot but continue to function. Get one bit wrong in a program that encompasses 100 million and the system may crash. That's 99.999999% correctness, or a thousand times better than the Five Nines requirement, and about two orders of magnitude better than Motorola's vaunted Six Sigma initiative.
Obviously, there are many kinds of error. A single bellicose bit might not have much of an effect, but then again, it could be earth-shaking.
Bugs destroy projects. They are the biggest cause of slipped schedules. We have all learned to fear the integration phase because of the typically inscrutable bugs that surface. They alienate customers and reputedly have led to bankruptcies.
There are a lot of reasons for bugs. One that's particularly pernicious is our expectation of them; our tolerance for mistakes. Most of us don't believe in perfection, and thus don't use that as the standard. And hence Jean's unwillingness to accept buggy code as a reason to use an MMU.
Companies that strive for PDP code usually achieve it. When that's the expectation, it gets achieved. Though PDP code is not necessarily more expensive than some of the crap that's shipped every year, it does mean the organization as a whole must be striving for perfection. The boss has to embrace the use of the right tools and techniques; his boss has to hold him accountable for getting a PDP product out the door.
The opposite is true: If the company expects buggy code, it'll get it. Joel Spolsky relates his experience on the Excel team when all that mattered was creating functionality. Developers responded predictably. To implement a function that computed a regression, for instance, they'd write:
float regression(args *in);
{
return(1);
}
Then it was just a matter of responding to bug reports from the testers.
Loading comments... Write a comment