Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Embedded software devt: The disciplined way (Part 2)

Posted: 22 Oct 2012 ?? ?Print Version ?Bookmark and Share

Keywords:Firmware? Code Inspections? bug rates?

For every measure think in terms of first collecting the data, then interpreting it to make sense of the raw numbers. Then figure on presenting the data to yourself, your boss, or your colleagues. Finally, be prepared to act on the new understanding.

Stop, look, listen. In the bad old days of mainframes, computers were enshrined in technical tabernacles, serviced by a priesthood of specially vetted operators. Average users never saw much beyond the punch card readers.

In those days of yore an edit-execute cycle started with punching perhaps thousands of cards, hauling them to the computer center (being careful not to drop the card boxes; on more than one occasion I saw grad students break down and weep as they tried to figure out how to order the cards splashed across the floor), and then waiting a day or more to see how the run went.

Obviously, with a cycle this long no one could afford to use the machine to catch stupid mistakes. We learned to "play computer" (sadly, a lost art) to deeply examine the code before the machine ever had a go at it.

How things have changed! Found a bug in your code? No sweata quick edit, compile, and re-download take no more than a few seconds. Developers now look like hummingbirds doing a frenzied edit-compile-download dance.

It's wonderful that advancing technology has freed us from the dreary days of waiting for our jobs to run. Watching developers work, though, I see we've created an insidious invitation to bypass thinking.

How often have you found a problem in the code, and thought "uh, if I change this maybe the bug will go away?" To me that's a sure sign of disaster. If the change fails to fix the problem, you're in good shape. The peril is when a poorly thought out modification does indeed "cure" the defect. Is it really cured? Did you just mask it?

Unless you've thought things through, any change to the code is an invitation to disaster. Our fabulous tools enable this dysfunctional pattern of behavior. To break the cycle we have to slow down a bit.

EEs traditionally keep engineering notebooks, bound volumes of numbered pages, ostensibly for patent protection reasons but more often useful for logging notes, ideas, and fixes. Firmware folks should do no less.

When you run into a problem, stop for a few seconds. Write it down. Examine your options and list those as well. Log your proposed solution (figure).

Figure: A personal bug log.

Keeping such a journal helps force us to think things through more clearly. It's also a chance to reflect for a moment, and, if possible, come up with a way to avoid that sort of problem in the future.

Identify bad code. Barry Boehm found that typically 80% of the defects in a program are in 20% of the modules. IBM's numbers showed 57% of the bugs are in 7% of modules. Weinberg's numbers are even more compelling: 80% of the defects are in 2% of the modules.

In other words, most of the bugs will be in a few modules or functions. These academic studies confirm our common sense. How many times have you tried to beat a function into submission, fixing bug after bug after bug, convinced that this one is (hopefully) the last?

We've all also had that awful function that just simply stinks. It's ugly. The one that makes you slightly nauseous every time you open it. A decent code inspection will detect most of these poorly crafted beasts, but if one slips through we have to take some action.

Make identifying bad code a priority. Then trash those modules and start over. It sure would be nice to have the chance to write every program twice: the first time to gain a deep understanding of the problem; the second to do it right. Reality's ugly hand means that's not an option.

But, the bad code, the code where we spend far too much time debugging, needs to be excised and redone. The data suggests we're talking about recoding only around 5% of the functionsnot a bad price to pay in the pursuit of quality.

Boehm's studies show that these problem modules cost, on average, four times as much as any other module. So, if we identify these modules (by tracking bug rates) we can rewrite them twice and still come out ahead.

Bugzilla is a free, open source, extremely popular bug tracking package. Use it with Scmbug to integrate the bug tracking software with Subversion or any other VCS.

Step 6: Measure your code production rates.
Schedules collapse for a lot of reasons. In the 50 years people have been programming electronic computers we've learned one fact above all: without a clear project specification any schedule estimate is nothing more than a stab in the dark.

Yet every day dozens of projects start with little more definition than "well, build a new instrument kind of like the last one, with more features, cheaper, and smaller." Any estimate made to a vague spec is totally without value.

?First Page?Previous Page 1???2???3???4???5???6?Next Page?Last Page

Article Comments - Embedded software devt: The discipli...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top