|
Embedded Muse 115 Copyright 2005 TGG September 2, 2005
You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.
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
The Muse has been on hiatus for the summer months, but is now active again. Thanks for everyone’s emails over the last few months!
Backups
Hurricane Katrina has wreaked havoc all along the US Gulf coast, and my sympathies go out to any of you affected by this tremendous tragedy. My son was in college in New Orleans but managed to get away in time. The Red Cross is accepting donations ( https://www.redcross.org/donate/donation-form.asp ).
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
Everyone knows that highly reliable software is intrinsically expensive… much more so than normal commercial-grade programs, right?
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
Check out http://www.csoonline.com/read/080105/debrief.html
Especially appropriate is their definition of “Backup.” It’s a process you don't need until you don't do it.