On Thu, 26 May 2005, Peter wrote:
> On Thu, 26 May 2005, John Ferrell wrote:
>> I have learned a lot from that book and I expect I will learn more...
>> I have come to believe there is no such thing as "error free" in this 
>> world.
>> 
>> John Ferrell
>> http://DixieNC.US
>> 
>>> I agree with you - I was disappointed with the number of errors in that 
>>> book.  I bought the first edition for the guys here at my shop - and was 
>>> unhappy enough not to purchase the second edition.  Looks as if that may 
>>> have been the right choice.
>
> According to the article about the Shuttle software posted on this list 
> earlier (and also according to figures from books) the expected error rate 
> for software is about 1% (reported to the number of lines of code). This is 
> not the number of typos, it is the number of logic errors. I tend to agree 
> with this number. It follows that if the book shows 1000 lines of code and 
> 1000 clauses (say, logical statements about bit functions and so on) it 
> should have about 10 errors in each group (and the errors in the clauses are 
> harder to catch because there is no easy way to compile the clauses).
>
> Peter

Having spent the better part of a decade working for an instrumentation
company, designing and releasing a new generation of an instrument line,
there are relatively modest things that can be done on a team to set the
culture and which can result in an order of magnitude, or even two,
lower error rates than similar teams working on similar projects in the
same building at the same time.

When we were done a dozen software people had produced half a million
bytes of embedded firmware that had to deal with a vast list of
interconnected hardware constraints.  Our error rate was one customer
out of 2000 using the instruments would find one bug each year.  That
translates into you and two dozen of your friends all using this full
time year round for fifty years and still having a 90% chance that not
a one of you would ever have seen a single bug, no matter how small.

Among other things, we included lots of sanity checks internally so that
any inconsistency found, no matter how small, would lock the instrument
up and display an error code with a message to call me and tell me
exactly what this said, that I could trace this to a specific line of
code. Those mostly served to show us the mistakes before we ever shipped
the first instrument.  But they also allowed me to precisely diagnose
and correct an error found by a customer thousands of miles away.

The other projects didn't worry about small errors, they were too busy
just trying to keep their box from crashing in the customer's hands.

Now we have two decades of experience with Windows, nobody seems to care
whether anything works or not, you just press the reset button or you
ignore the problem or you buy a new version every six months and find
different errors.  Being able to pump out new versions with lots of
new features, who cares if it works, we don't have time for that, that
is what matters now, mostly.  Our box, the one with almost no errors,
was cancelled a couple of years after introduction.  The other boxes,
the ones with a nighmare of software problems but who accidentally
happened to have different marketing features, they went on to be a
success that needed many times our design time just to patch their
bugs and keep them going.

Someone should have slapped me up against the wall, told me this, and
repeated this until I understood, early in my career.  It would have
saved me a lot of grief and the company a lot of money.

(Just spent two days trying to figure out why voice input to a Windows
system, that had been working fine, now doesn't work any more.  Made
no changes.  No diagnostics can point me at what the problem is.  And
the more things I change trying to discover the source of the problem
the more I expect I'm just making it worse)
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist