Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Universal laws of bugs?

by belg4mit (Prior)
on Mar 09, 2003 at 05:20 UTC ( #241503=perlmeditation: print w/ replies, xml ) Need Help??

  1. If you upload it to CPAN it will break.
  2. If it passed all the tests first it will break even more.

--
I'm not belgian but I play one on TV.

Comment on Universal laws of bugs?
Re: Universal laws of bugs?
by dws (Chancellor) on Mar 09, 2003 at 06:32 UTC
    1. Bugs travel in groups. If you see one, look for a second. If you see two close together, look for eight more.

    2. It's never the case that "nothing changed, really!" If you're sure that nothing changed, look again.

    3. The solution will pop out the moment somebody looks over your shoulder. Therefore, arrange for people to look over your shoulder a lot. Better yet, pair program.

    4. The best insurance against bugs sneaking in is a good set of unit tests, run frequently. When you fix a bug, write a new unit test that demonstrates the bug first, then fix it. That way, the bug will stay fixed.

    5. Demos to customers attract bugs. Demo to a friendly audience first.

    6. Remember Rudy's Rutagaba Rule (Weinberg): "Once you eliminate your number one problem, number two gets a promotion." Having another problem is a good thing. It means you still have customers.

Re: Universal laws of bugs?
by hsmyers (Canon) on Mar 09, 2003 at 08:16 UTC
    1. A skipped regression test is absolute proof of the existance of a fatal bug.
    2. The only sure way to write bug-free code is not to run it...er...not to write it...er...don't even think about it!
    3. Even faster than a code-walk-through is try-and-impress-someone.
    4. A good project manager may not have been 100% accurate about the going-gold date---use the false announcement to 'scare' out a few more of the little critters!

    --hsm

    "Never try to teach a pig to sing...it wastes your time and it annoys the pig."
Re: Universal laws of bugs?
by gmax (Abbot) on Mar 09, 2003 at 10:08 UTC
    Rule Corollary
    It won't break until you've forgotten how that clever hack works. The only thing you recollect is that you were very proud of such hack, but damn if you can remember why!
    It will break when you are busy creating the software masterpiece of your life, when you can't be distracted by old silly bugs. You will screw up both the old code and the would be masterpiece as well.
    It will break when you are boarding the plane for your honeymoon and you forgot to switch off your pager. Your wife will leave you saying "I can't believe this. You wrote a module without using strict!"
     _  _ _  _  
    (_|| | |(_|><
     _|   
    

      Secondary corollary to the third case: Your wife has learned at least enough perl to nag you about your bad coding habits. ;)


      Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Re: Universal laws of bugs?
by PodMaster (Abbot) on Mar 09, 2003 at 13:20 UTC
    No. Those would be
    • If you share it, more bugs will become apparent
    • If it passed all tests, buggy tests will become apparent
    Most common problem cpan-testers see is that the tests are written with no portability in mind. Tests that should be skipped, usually aren't, filepaths are being compared without being run through File::Spec first...


    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
    ** The Third rule of perl club is a statement of fact: pod is sexy.

      In addition

      • If it passed all tests, then you need to write at least one more test.
Re: Universal laws of bugs?
by Wysardry (Pilgrim) on Mar 09, 2003 at 15:10 UTC

    Hey, if you want to make it foolproof, you better get a whole string of fools to test it. :o)

    __________
    "Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work." -- (Author Unknown)

      There is no such thing as "fool-proof." As I once heard it (and unfortunately, I do not know whom to attribute it to) to the effect that, "Programming is the race between programmers to write programs that are fool-proof, and the Universe to create better fools... and so far, the Universe is winning."

        Well, yes, "fool-resistant" would likely be a better term, but I've never heard of anyone using it. ;o)

        I used it in the same context as "bulletproof", which is only accurate if standard/average bullets are used. Even armour plating isn't proof against armour piercing rounds, and whenever better armour is produced a better bullet will surely follow.

        All anyone can ever hope to achieve in any given task, is their own personal best under whatever restrictions are placed upon them - such as time, money and the involvement of other (possibly less perfect) people.

Re: Universal laws of bugs?
by Anonymous Monk on Mar 09, 2003 at 15:44 UTC

    ahem.

    • If you don't write adequate tests, you will have bugs.
    • If you do not continually run these tests, you will have bugs.
    • If you can't immediately refute 99% of the content in mainstream programming theory books, you will have bugs.
    • If you think the above type of books are "genius" or in anyway new and innovative in the slightest (even at their time of publication), you will have bugs.
    • If you do not consider all program input as something more poisonous than arsenic, you will have bugs.
    • If you give into rushed schedules and sacrifice design, you will have bugs.
    • If you implement needless features that add nothing to the product, you will have bugs.
    • If you do not clearly separate your data from your code, you will have bugs.
    • If you only hire people based on university degrees, you will have bugs.
    • If you ever, ever hire an external consultanting firm to write software, you will have bugs.
    • If you insist on a language that is inappropriate for the job, you will have bugs.
    • If you fail to continually train your employees, you will have bugs.

    And as far as ones I tell the brass:

    • If you don't provide adequate caffeine products, you will have bugs.
    • If employees don't play 2 hours of video games per work day, you will have bugs.
    • If you hire me a coworker like milton or a manager like Lumburgh, you will have bugs (and my boot shoved somewhere unpleasant).

      If you give into rushed schedules and sacrifice design, you will have bugs.

      Too bad that in deciding whether or not to give in, I sometimes have to give the paycheck more weight than the risk of bugs....

Re: Universal laws of bugs?
by webfiend (Vicar) on Mar 09, 2003 at 15:55 UTC

    Great thread. I like to see how we think in here. Bunch of optimists, right? ;-)

    Personally, I think it boils down to a single truism passed down through generations of household repairmen, wood shops, and millenia of men trying to fix or build things:

    • If it hasn't broken yet, you aren't trying hard enough.

    I just realized that I was using the same sig for nearly three years.

Re: Universal laws of bugs?
by submersible_toaster (Chaplain) on Mar 10, 2003 at 00:09 UTC
    • If I wrote it, it has bugs I cannot find but know how to fix.
    • If THEY wrote it, it has bugs I can find but can't fix.
    • If it isn't written, there's a bug somewhere looking for a home.


    I can't believe it's not psellchecked
Re: Universal laws of bugs?
by Abigail-II (Bishop) on Mar 10, 2003 at 00:41 UTC
    This entire thread can be summed up with one of the mottos of the monastry: "All software sucks".

    To paraphrase the late E. W. Dijkstra, we have only been programming for a few decades. We can't even answer the fundamental question whether programming is hard or not.

    Abigail

      This entire thread can be summed up with one of the mottos of the monastry: "All software sucks".

      Not all software sucks... Some of it blows.

      One huge software company, against all logic, even manages to create software that both sucks and blows at the same time. ;o)

      __________
      "Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work." -- (Author Unknown)

      We can't even answer the fundamental question whether programming is hard or not.

      Take it from one who's still struggling to tie his laces (programmatically). Programming is hard! It's coding that's easy.

      It's easy to write a bit of code that does a specific "thing" ... I do it all the time.

      What I still am struggling to get right is to write that same bit of code so that it is:
      1.) Usable in more than just the one situation it was coded for.
      2.) Stable in an unstable world.
      3.) Looks good (i.e. Others can understand it.)
      4.) Doesn't get me a metaphorical clout accross the skull when another programmer sees it.

      Maybe I've swopped the "correct" definitions of coding and programming around? :-)

      So Long
      blackstarr

        1 - see CPAN, modularization is easy 'nuff said. 2 - Logic. Just understand basic logic. No one can break logical code unless they invent a square circle. 3 - Don't drop the the lowest common programmer. Just keep it relatively simple and you'll be find (common sense stuff, break complex operations into multiple lines, etc) 4 - Program for yourself and you won't need to worry about this.

Re: Universal laws of bugs?
by Biker (Priest) on Mar 10, 2003 at 15:45 UTC

    In our offices we have agreed on:

    • Every program can be reduced in size by at least one byte
    • Every program contains at least one bug

    As a result, we also agree that every program can be reduced to one byte, where the byte contains the bug. Then we delete the buggy byte...


    Everything went worng, just as foreseen.

Re: Universal laws of bugs?
by tbone1 (Monsignor) on Mar 12, 2003 at 11:54 UTC
    Users will do any dern-fooled thing that no sensible person would; each of these dern-fooled things will cause at least one bug that does not behave as you'd expect.

    --
    tbone1
    Ain't enough 'O's in 'stoopid' to describe that guy.
    - Dave "the King" Wilson

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://241503]
Approved by rob_au
Front-paged by gmax
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2014-09-22 02:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (177 votes), past polls