Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

Matts
  (email not shown publicly)

I work for MessageLabs [messagelabs.com] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Saturday September 11, 2004
03:57 PM

Many eyes

[ #20836 ]

In open source there's a well known fallacy: "Given enough eyeballs, all bugs are shallow". This has not been my experience.

In my experience there's only one true way to fix bugs: replicate them.

And so the modern day way to replicate bugs is to implement the bug in a .t file. In all my recent large scale projects this has been the only successful way to locate difficult/complex bugs, and get them fixed. Beyond that, having a .t file ensures the bug doesn't creep back in.

Yes, this is another "tests are good" post. But I really believe that those who don't code with tests in mind are not yet enlightened to the "next level" of software development, and probably need a swift kicking in that direction.

The reason for posting this: I struggled for ages to try and figure out what was causing problems with concurrent access to our SQLite databases. I tried to think it through, and just wonder about the problem. I came to the (wrong) conclusion that there was something wrong with our network. Until we wrote a test. Once the test was written the solution dropped out in a few minutes. I'm kicking myself for not doing that sooner (though I can't blame myself too much as I'm not assigned to the project that uses SQLite any more).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The "many eyes" fallacy persists because there's a grain of truth lurking inside.

    Of course, the "many eyes" are not enough to fix bugs. What you need are "many hands", as in "many hands make light work". The reason why open development models trump closed development models is because closed shops have a fixed number of staff, generally managed so they have as little slack as possible.

    Open development models, on the other hand, are open to the possibility that someone out there (someone you never met,

  • ""Given enough eyeballs, all bugs are shallow". This has not been my experience. In my experience there's only one true way to fix bugs: replicate them."

    For some reason, I read this as a plan to replicate eyeballs. Y'know, it just might work...