Embedded Muse 115 Copyright 2005 TGG September 2, 2005

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Backups
- Productivity Vs Process
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

Backups

According to the NY Times ( http://nytimes.com/cnet/CNET_2100-1011_3-5845894.html ) the devastation made companies in other areas aware of the potential for disaster if their on-site data and backups were submerged under 10 feet of water. There’s a spike in business for vendors of off-site data storage this week.

We developers should be wary, too. Our work products are data, the ones and zeroes that represent firmware or CAD designs. One glitch, mistake, or natural disaster could wipe out the company. I see these problems happen all the time.

A few years ago the FAA announced they had lost the source code to all of the software that controlled air traffic between Chicago and the regional airports. The code all lived on one developer’s machine, one angry person who quit and deleted it all. He did, however, install it on his home computer, encrypted. The FBI spent 6 months reverse engineering the encryption key to get their code back.

Appalling? You bet. But these incidents are far from rare.

Before even thinking about building any sort of software, install and use a version control system (VCS). Building even the smallest project without a VCS is a waste of time and an exercise in futility.

Without a VCS, a failure of any engineer’s computer will mean you lose code, since it’s all inevitably scattered around amongst the development team.

The version control database – the central repository of all of your valuable software – lives on a single server. Daily backups of that machine, stored offsite, insures your business’s survival despite almost any calamity. Offsite storage is best done in a place a thousand miles from the main office in case a hurricane or earthquake takes out an entire region.

Version control systems range in price from free (like the GNU products) to expensive, but even the expensive ones are cheap. See http://better-scm.berlios.de/comparison/comparison.html for a comprehensive list of products.

There’s no excuse for losing data.

Productivity Vs Process

Maybe not.

The Capability Maturity Model is either reviled or loved. It layers lots of heavyweight process on the development team in an effort to build more reliable code. Yet companies that aggressively pursue the CMM gain something like 33% productivity per year.

O. Benediktsson (Safety Critical Software and Development Productivity, conference proceedings, Second World Conference on Software Quality, Sept 2000) looked at the cost to build software at different levels of process maturity. They created the odd terms “VI” and “CI.” “VI” means Verifiability Index. It’s a measure of the cost of a failure, and is defined as follows:

Nominal – Moderate, easily recoverable losses
VI1 – High financial loss
VI2 – Very high financial loss
VI3 – Human life at risk

“CI” is the Capability Index and is roughly equivalent to CMM levels 1 to 4.

The relative cost to build a product, they claim, is a function of the team’s process maturity and the product’s reliability, as follows:

Nominal VI1 VI2 VI3
Nominal 1.00 1.15 1.28 1.70
CI1 0.94 1.08 1.20 1.60
CI2 0.74 0.85 0.95 1.26
CI3 0.56 0.65 0.72 0.95

Read down the diagonal from “Nominal, Nominal” to “VI3, CI3.” We can build safety critical software for the same cost as the usual shoddy stuff if we increase our process maturity!

Or, we can build the usual crud faster and cheaper by improving our processes.

Obviously, any process can be, and often is, subverted. I visited a CMM5 organization not long ago that doesn’t use code inspections, though these are required at level 3. Somehow they’d gotten certified yet this one team, at least, is clueless about the requirements of the CMM.

There are a zillion different methods – processes – for building software. Most of the embedded world uses little or none, whether it’s a monstrous heavyweight one like the CMM or any of the Agile methods.

And that’s a darn shame, considering the data shown above.

Jobs!

Joke for the Week