embedded note

[John Larkin]

http://www.eetimes.com/showArticle.jhtml?articleID=47900091

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "

John

 

[Paul Hovnanian P.E.]

John Larkin wrote:

http://www.eetimes.com/showArticle.jhtml?articleID=47900091

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "

Both quality control methods have their place. They tend to expose
different types of software problems.

--
Paul Hovnanian mailtoaul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
Matter cannot be created or destroyed, nor can it be returned without a
receipt.

 

[Tim Wescott]

Paul Hovnanian P.E. wrote:

John Larkin wrote:

http://www.eetimes.com/showArticle.jhtml?articleID=47900091

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "


Both quality control methods have their place. They tend to expose
different types of software problems.

And neither one can do much of anything in an environment where software

quality is viewed as "overhead".

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Joerg]

Hi John,

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "


Only if the inspection is done by people other than the designers of the

code. I believe real tests are inevitable and wouldn't release anything
without that.

One very good strategy is to employ procedures similar to those for FDA
filings for medical equipment, 510(k) and PMA filings. These follow
hazard flow charts and must contain a complete hazard and mitigation
analysis. It is similar for aircraft equipment. Even for more mundane
designs it might pay to peek over the fence.

Regards, Joerg

http://www.analogconsultants.com

 

[John Larkin]

On Sat, 25 Sep 2004 18:08:43 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

Hi John,

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "


Only if the inspection is done by people other than the designers of the
code.

I read my own code carefully, several times, and find most of my bugs
that way. Funny, the ones that are left for testing are usually really
gross, like instant crashes, and they're not hard to find or fix.

I believe real tests are inevitable and wouldn't release anything
without that.

Certainly.


John

 

[Joerg]

Hi John,

I read my own code carefully, several times, and find most of my bugs
that way.

That is great. I wish most engineers would do that. That would cut

design review time substantially. Once I asked a group what would happen
if the valve were in the open position and then the clock to the uC
would stop for some reason. Loooong silence, a faint "oh shoot..." from
someone and then weeks of redesign.

Regards, Joerg

http://www.analogconsultants.com

 

[John Woodgate]

I read in sci.electronics.design that Joerg <notthisjoergsch@removethisp
acbell.net> wrote (in <kak5d.1436$JG2.1235@newssvr14.news.prodigy.com&gt
about 'embedded note', on Sat, 25 Sep 2004:

That is great. I wish most engineers would do that. That would cut
design review time substantially. Once I asked a group what would happen
if the valve were in the open position and then the clock to the uC
would stop for some reason. Loooong s

Students should be trained on those 'truth table' puzzles you can get in
cheap books. Then show them how to use them for real.
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

 

[Joerg]

Hi John,

Students should be trained on those 'truth table' puzzles you can get in
cheap books. Then show them how to use them for real.


Other things they should learn: Good software work requires the writing

of a document starting from top level, not just a few comment lines in
the code. Writing that document should not be procrastinated on until
after the project when the QC guy bugs them and there is no time. How to
design fail-safe architectures, assuming that those ideal parts they see
in their books can and do fail. How to anticipate and mitigate the
weirdest mistakes a user can make.

Regards, Joerg

http://www.analogconsultants.com

 

[Clifford Heath]

John Larkin wrote:

I read my own code carefully, several times, and find most of my bugs

It takes most people a long time to learn to do that. One of the
best ways to teach people not to put bugs in their code is to
subject everything they write to critical inspection by their
peers. They soon learn that it has to be got right anyway,and
it's less embarrassing to do it *before* the code review.
We review every code change, and though sometimes I think the
"critical" aspect is lacking, it still helps.

 

[Paul Hovnanian P.E.]

Tim Wescott wrote:

Paul Hovnanian P.E. wrote:
John Larkin wrote:

http://www.eetimes.com/showArticle.jhtml?articleID=47900091

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "


Both quality control methods have their place. They tend to expose
different types of software problems.

And neither one can do much of anything in an environment where software
quality is viewed as "overhead".

That's one good selling point for more code reviews. The review comes
before the product is released. Once the marketing folks have a
'working' copy, they can cut testing short.

--
Paul Hovnanian mailtoaul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
I think you left the stove on.

 

[Ken Smith]

In article <n1gbl05msqu5sknmqnv7ctpghki9mjebeh@4ax.com>,
John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote:

On Sat, 25 Sep 2004 18:08:43 GMT, Joerg
notthisjoergsch@removethispacbell.net> wrote:

Hi John,

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "


Only if the inspection is done by people other than the designers of the
code.

I read my own code carefully, several times, and find most of my bugs
that way.

Its even quicker to just not put the bugs in, in the first place. :>

There is some truth to it. An extra hour of careful design can save a day
of debugging.

I'm about 1/2 way through the software on my current project. The
comments outnumber the lines of code by about 2:1. When I'm done that
will be reduced to about 1.5:1.


--
--
kensmith@rahul.net forging knowledge

 

[Paul Hovnanian P.E.]

Joerg wrote:

Hi John,

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "


Only if the inspection is done by people other than the designers of the
code. I believe real tests are inevitable and wouldn't release anything
without that.

One very good strategy is to employ procedures similar to those for FDA
filings for medical equipment, 510(k) and PMA filings. These follow
hazard flow charts and must contain a complete hazard and mitigation
analysis. It is similar for aircraft equipment.

Be careful using that as a positive example. We used to call that
paperwork "FAA appeasement documents" since the design was effectively
frozen before the analysis was performed.

Even for more mundane
designs it might pay to peek over the fence.

Regards, Joerg

http://www.analogconsultants.com

--
Paul Hovnanian mailtoaul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
From the moment I picked your book up until I put it down I was
convulsed with laughter. Some day I intend reading it.
-- Groucho Marx, from "The Book of Insults"

 

[John Larkin]

On Sat, 25 Sep 2004 22:35:23 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

Hi John,

Students should be trained on those 'truth table' puzzles you can get in
cheap books. Then show them how to use them for real.


Other things they should learn: Good software work requires the writing
of a document starting from top level, not just a few comment lines in
the code. Writing that document should not be procrastinated on until
after the project when the QC guy bugs them and there is no time. How to
design fail-safe architectures, assuming that those ideal parts they see
in their books can and do fail. How to anticipate and mitigate the
weirdest mistakes a user can make.

Why not make the "document" part of the code source? That way, you
don't have two separate docs to maintain and keep coherent.

John

 

[Richard Henry]

"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote in
message news:ms79l0pdbdiugqkbspie40b7inspke15f6@4ax.com...

http://www.eetimes.com/showArticle.jhtml?articleID=47900091

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "

That may be because the code inspection, if properly done, occurs before the
testing.

 

[john jardine]

"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote in
message news:ms79l0pdbdiugqkbspie40b7inspke15f6@4ax.com...

http://www.eetimes.com/showArticle.jhtml?articleID=47900091

"He cited studies that conclude that code inspections are about 20
times more efficient at detecting bugs than testing. "

John

Well he would, cos he'll be making money from pushing code inspection. Bit
like the year 2000 'bug' or the firewall and virus detection salesmen or
those fabled '100% certain' code validators.
Good progs only result from employing clever, wise, well blooded,
experienced programmers. Good programmers only come about from having made
lots and lots of embarassing mistakes. The very best programmers
unfortunately, prefer to spend all their time writing games.
regards
john

 

[John Larkin]

On Sun, 26 Sep 2004 00:01:44 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

Hi John,

Early-on in the system's life, one BART train crashed into another
because all the redundant safety logic froze when the single crystal
oscillator clock stopped.


That is really poor engineering. The least they should have done is the
electronic equivalent of a dead-man switch. Don't know if they still
have them but in Europe the train engineer had to push a button
regularly. If he or she didn't the train would stop. On BART they would
have needed something like that for the controller. If a certain pulse
that would have been generated by the firmware failed to appear again
within x msec the train should have automatically stopped by means of
uncommitted hardware. It's the basic watchdog concept.

One of my temperature controllers can do maybe $100K of damage if the
uP crashes and the PWM output freezes, so I have a one-shot and a
relay in the heater circuit. If the one-shot isn't refreshed, the
relay drops. That's on top of the usual software protections. So the
customer's system software had a bug and would occasionally send me a
serial command to go to 3000C, which I dutifully tried to do. Fried a
bunch of expensive systems. I had to build a black-box data logger
into my code to catch them doing it. Their code was a nightmare of
patched, uncommented, stuff-commented-out-nobody-remembers-why C++. I
never did meet, or even get to talk to, the programmers involved; they
couldn't be bothered. They patched it some more and the problem went
away.


Did they try to stiff you for the damages caused?

No, but they assumed it was the controller's fault until we (entirely
under the table) installed the blackbox recorder at a customer site
and caught the 3000C command red-handed. Since then, I've added a
hightemp shutdown limit that can only be set from the front panel of
our box, not by the system software. Part of the problem was that our
box had to work with an abysmal historical serial comm protocol that
was disaster waiting to happen.

Don't know the ratio of friends/enemies created by that little
exercize.

John