Re: "Am I still working okay?" asked the micro controller...
From: David (FlyLikeAnEagle_at_United.Com)
Date: 05/28/04
- Next message: Al Borowski: "Re: How to choose a firmware partner"
- Previous message: Satisfaction: "Re: new members coming in AT91 family"
- In reply to: Guy Macon: "Re: "Am I still working okay?" asked the micro controller..."
- Next in thread: Gerald Bonnstetter: "Re: "Am I still working okay?" asked the micro controller..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 28 May 2004 01:06:07 GMT
On Wed, 19 May 2004 21:09:45 UTC, Guy Macon <http://www.guymacon.com> wrote:
>
> Don Taylor <dont@agora.rdrop.com> says...
>
> >it was feasible to write one, or a small number, of "sanity checks",
> >small tests that would evaluate whether arguments being passed and/or
> >state variables had values that were appropriate at the moment.
> >
> >If a sanity check failed we displayed "Fatal Error nnnnn", where nnnnn
> >was the program counter at the point where the check failed, and then
> >we halted the processor.
>
> [snip]
>
> Don, may I have permission to put your story up on my web page?
>
>
> Here is another technique which I use:
>
> Start with "finished" and "debugged" code.
>
> Have one programmer insert N bugs in another programmer's code, keeping
> careful records of what and where. The idea is to put in errors typical
> of the errors that the person writing the code normally makes.
>
> Have the author of the code debug and fix all bugs that he can find,
> stopping when he can't find any more bugs. Keep record of all bugs
> fixed. Don't tell him which are his or how many were inserted.
>
> Let's say that we inserted 20 bugs, he found 10 of them, and he found
> 20 of his own bugs. That tells us that there are around 20 of his
> own bugs still undiscovered.
>
> The psychology is interesting. The programmers write code with far
> fewer bugs and do a far better job of testing before saying that they
> are done. The programmer who finds all of the inserted bugs and no
> new bugs is a hero. (I reinforce that with bonuses and with specific
> mention in writing of this accomplishment during performance reviews.)
I use a similar technique to keep the developers and validators
thinking. Developers occasionally add little changes that aren't
specified or are true mistakes. The validators occasionally report
or demonstrate problems that are fictitious. Both groups keep tabs
on each other.
Worried that your new function isn't properly tested? Break it
or add something silly like an off-color display or easter egg.
After a change is validated, break it again a litle while later
and see if a regression test was done.
Worried that a developer isn't paying attention? Report an
error that was fixed or can't happen. See how long it takes
to discover the hoax. If you are evil and spot a developers
terminal unoccupied, make a small change -- wording, duplicate
line, etc.
Each group can play the game. Does your develper sneak in
undocumented code changes? Do random check on version control.
Will the person checking in the final code notice the random
comment "XYZ checked in this code and didn't notice; owes ABC
a snickers bar." Did the manager really read that status
report or design document?
Good natured fun can liven up the group and keep them 'awake'.
David
- Next message: Al Borowski: "Re: How to choose a firmware partner"
- Previous message: Satisfaction: "Re: new members coming in AT91 family"
- In reply to: Guy Macon: "Re: "Am I still working okay?" asked the micro controller..."
- Next in thread: Gerald Bonnstetter: "Re: "Am I still working okay?" asked the micro controller..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
