Perfect software

March 01, 2009

JackGanssle-March 01, 2009

Whence perfection?
Though I love Jesse Poore's quote mentioned earlier, perfection is an idealistic dream for most of us. I'm sure Jean Labrosse would argue vehemently, and I admire him greatly for his stand and his success at achieving it. But in this world of million-line programs, I have seen no evidence that perfection is about to take the embedded world by storm.

But we should expect PDP. Code that works and that we're utterly confident in when we ship it. Code that has been crafted from the beginning to be correct, using techniques long understood to lead to quality. Standards, inspections, design reviews, decent specs and the use of tools like lint and static analyzers that scrutinize its construction and behavior.

Tests are important: PDP tests that overlook nothing. I suspect the unit tests the Excel team employed were, shall we say, /PDP. The test code needs the same attention to detail as that for the end product. Today, sadly, most test code is considered throwaway garbage not worth a lot of effort.

The statistics are bleak: Typical test routines exercise only half the code. Worse, few of us have any quantitative knowledge of how many tests are needed. Do you run cyclomatic complexity figures on your products? Cheap tools compute it automatically. The complexity gives a minimum number of tests that must be run to ensure that a function is completely tested. We need to use these sorts of metrics to audit our testing. I wrote about this last year ("Taming software complexity," March 2008, (www.embedded.com/206901032).

One of the most brilliant things to come from the agile movement is their focus on automated testing. That can be tough in the embedded world where someone has to press the buttons and watch the displays, and I see few teams in this industry that have excellent automated tests.

Some agilists take me to task; they suggest using mock objects to simulate the hardware. It's a nice and worthwhile idea, but always merely a simulation. Real tests are important and some clever people have created cool external test environments. Several companies I know aim a video camera at the displays and use LabVIEW to interpret the results, closing the test loop using an external computer.

That's pretty cool.

PDP code also often needs built-in surge protectors like those beefy beams and oversized wires. Things do go wrong. Even perfect code and perfect hardware does not necessarily mean a product is PDP. Stuff happens. EMI, EMP (well, hopefully not), brownouts and other effects can disrupt execution. Cosmic rays are increasingly disruptive as device geometries shrink.

It's amazing that computers work at all. A PC moves billions of bits around every second. The voltage difference between a zero and a one keeps shrinking. If any one of those bits is corrupted by a cosmic ray something will go noticeably wrong. We depend on that reliability and expect it. But it's not at all clear to me that expectation is reasonable.

< Previous
Page 3 of 4
Next >

Loading comments...

Most Commented

Parts Search Datasheets.com

KNOWLEDGE CENTER