Jack Ganssle has a nice design article that details a long history of design errors, from bridge building to safety critical software problems. Much of it is about NASA mission failures, but he also checks in on the topics of radiation therapy, pacemakers, and nuclear experiments. Good one-stop shopping for horror stories and a discussion of high level patterns behind these sorts of problems.
On discussing the Therac 25:
"The FDA found the usual four horsemen of the software apocalypse at fault: inadequate testing, poor requirements, no code inspections, and no use of a defined software process."
Quote of the day from the article:
"Globals are responsible for all of the evil in the universe, from male pattern baldness to ozone depletion."
Source: Mars Ate My Spacecraft
Companion blog to the book Better Embedded System Software by Phil Koopman at Carnegie Mellon University
Wednesday, April 27, 2011
Monday, April 18, 2011
Peer Reviews are Cheap
In previous posts I've talked about how useful peer reviews can be. But some many folks say they are just too expensive. That just isn't so. Here's the math.
You can write good embedded software at the rate of 1-2 lines of code per hour. (That is all source lines of code divided by all hours for a project, including requirements, test, etc. Really, that is the number.)
Formal, rigorous, thorough peer reviews target 100-200 lines of code reviewed per hour (we're talking Fagan style inspections, which are quite formal, but still the most cost effective review method from all the data I've seen). Let's say you have 4 people in an inspection. That is 25-50 lines of code per person-hour. If you include an hour of prep time for each person for a two-hour review, that is still 17-33 lines of code per person-hour.
Think you write code faster? OK, let's say you're Agile and do 3 lines of code/hr (what I've seen in industry, and comes with increased risk we can discuss elsewhere). That's still nowhere near the review productivity rate.
We're talking maybe 5%-10% of project effort to do heavy-weight reviews. And it generally finds half the bugs. More importantly, it finds them early, so you don't have a lot of rework.
So why does everyone say it is too expensive?
You can write good embedded software at the rate of 1-2 lines of code per hour. (That is all source lines of code divided by all hours for a project, including requirements, test, etc. Really, that is the number.)
Formal, rigorous, thorough peer reviews target 100-200 lines of code reviewed per hour (we're talking Fagan style inspections, which are quite formal, but still the most cost effective review method from all the data I've seen). Let's say you have 4 people in an inspection. That is 25-50 lines of code per person-hour. If you include an hour of prep time for each person for a two-hour review, that is still 17-33 lines of code per person-hour.
Think you write code faster? OK, let's say you're Agile and do 3 lines of code/hr (what I've seen in industry, and comes with increased risk we can discuss elsewhere). That's still nowhere near the review productivity rate.
We're talking maybe 5%-10% of project effort to do heavy-weight reviews. And it generally finds half the bugs. More importantly, it finds them early, so you don't have a lot of rework.
So why does everyone say it is too expensive?
Subscribe to:
Posts (Atom)
Static Analysis Ranked Defect List
Crazy idea of the day: Static Analysis Ranked Defect List. Here is a software analysis tool feature request/product idea: So many times we...
-
It is common to see small helper functions implemented as macros, especially in older C code. Everyone seems to do it. But you should ...
-
(If you want to know more, see my Webinar on CRCs and checksums based on work sponsored by the FAA.) If you are looking for a lightwei...
-
Oct 3, 2014: updated with video of the lecture Here is my case study talk on the Toyota unintended acceleration cases that have been in ...