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

Embedded software devt: The disciplined way (Part 2)

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

Keywords:Firmware? Code Inspections? bug rates?

Yet the cube police will rarely listen to data and reason. They've invested in the cubes, and they've made a decision, by God! The cubicles are here to stay!

This is a case where we can only wage a defensive action. Educate your boss but resign yourself to failure. In the meantime, take some action to minimize the downside of the environment. Here are a few ideas:

1) Wear headphones and listen to music to drown out the divorce saga next door.

2) Turn the phone off. If it has no "off" switch, unplug the damn thing. In desperate situations attack the wire with a pair of wire cutters. Remember that a phone is a bell that anyone in the world can ring to bring you running. Conquer this madness for your most productive hours.

3) Know your most productive hours. I work best before lunch; that's when I schedule all of my creative work, all of the hard stuff. I leave the afternoons free for low-IQ activities like meetings, phone calls, and paperwork.

4) Disable the email. It's worse than the phone. Your 200 closest friends who send the joke of the day are surely a delight, but if you respond to the email reader's "bing" you're little more than one of NASA's monkeys pressing a button to get a banana.

5) Put a curtain across the opening to simulate a poor man's door. Since the height of most cubes is rather low, use a Velcro fastener or a clip to secure the curtain across the opening. Be sure others understand that when it's closed you are not willing to hear from anyone unless it's an emergency.

It stands to reason we need to focus to think, and that we need to think to create decent embedded products. Find a way to get some privacy, and protect that privacy above all.

(When I use the Peopleware argument with managers they always complain that private offices cost too much. Let's look at the numbers. DeMarco and Lister found that the best performers had an average of 78 square feet of private office space. Let's be generous and use 100. In the Washington DC area in 1998 nicevery nicefull service office space runs around $30/square foot/year.

Cost: 100 square feet: $3000/year = 100 sq ft * $30/ft/year

One engineer costs: $120,000 = $60,000 * 2 (overhead)

The office represents: 2.5% of cost of the worker = $3000/$120,000

Thus, if the cost of the cubicle is zero, then only a 2.5% increase in productivity pays for the office! Yet DeMarco and Lister claim a 260% improvement. Disagree with their numbers? Even if they are off by an order of magnitude a private office is 10 times cheaper than a cubicle. You don't have to be a rocket scientist to see understand the true cost/benefit of private offices versus cubicles. )

Step 5: Measure your bug rates.
Code inspections are an important step in bug reduction. But bugssome bugswill still be there. We'll never entirely eliminate them from firmware engineering.

Understand, though, that bugs are a natural part of software development. He who makes no mistakes surely writes no code. Bugsor defects in the parlance of the software engineering communityare to be expected. It's OK to make mistakes, as long as we're prepared to catch and correct these errors.

Though I'm not big on measuring things, bugs are such a source of trouble in embedded systems that we simply have to log data about them. There are three big reasons for bug measurements:

1) We find and fix them too quickly. We need to slow down and think more before implementing a fix. Logging the bug slows us down a trifle.

2) A small percentage of the code will be junk. Measuring bugs helps us identify these functions so we can take appropriate action.

3) Defects are a sure measure of customer-perceived quality. Once a product ships we've got to log defects to understand how well our firmware processes satisfy the customerthe ultimate measure of success.

But first a few words about "measurements." It's easy to take data. With computer assistance we can measure just about anything and attempt to correlate that data to forces as random as the wind.

Demming noted that using measurements as motivators is doomed to failure. He realized that there are two general classes of motivating factors: the first he called "intrinsic."

This includes things like professionalism, feeling like part of a team, and wanting to do a good job. "Extrinsic" motivators are those applied to a person or team, such as arbitrary measurements, capricious decisions, and threats. Extrinsic motivators drive out intrinsic factors, turning workers into uncaring automatons. This may or may not work in a factory environment, but is deadly for knowledge workers.

So measurements are an ineffective tool for motivation. Good measures promote understanding : to transcend the details and reveal hidden but profound truths. These are the sorts of measures we should pursue relentlessly.

But we're all very busy and must be wary of getting diverted by the measurement process. Successful measures have the following three characteristics:

1. They're easy to do.

2. Each gives insight into the product and/or processes.

3. The measure supports effective change-making. If we take data and do nothing with it, we're wasting our time.

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



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

Seminars

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

?
?
Back to Top