Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Programming Laws

by dreadpiratepeter (Priest)
on Jan 24, 2002 at 19:55 UTC ( [id://141227]=perlmeditation: print w/replies, xml ) Need Help??

Inspired by the recent Programming Mantras thread, I wonder does anyone else have any 'murphy-like' programming laws?
I'll start:

Pete's Law of Cloned Code
<quote> "The number of errors in a block of code is directly proportional to the number of times you just cloned it." </quote>

Entropy is not what is used to be.

Replies are listed 'Best First'.
(Ovid) Re: Programming Laws
by Ovid (Cardinal) on Jan 24, 2002 at 21:41 UTC

    Ovid's Law of Security

    Allowing a known security weakness into a program is automatically a security hole, regardless of whether or not it can be exploited.

    Okay, so it's a bit wordy, but it's true. I've seen this too many times to think otherwise. I was bit by this a few months ago. I was told that I had to get a page up fast. I had to write a program to regularly grab financial data from some files that are sent to us via ftp. Then, this data is stored in a database and later served on a page.

    The program that actually gets the data from the database was thrown together in a few hours. Since I was rushed, I was lazy (the bad lazy, not the good) and put the username and password for the database into the script. Hey, this is in the cgi-bin directory and no one will ever see it. Naturally, a couple of weeks later, someone had to move the site and misconfigured the server. Instead of running the script, it was being sent to the browser.

    I knew it was a weakness and it's a trivial matter to move the username and password to a config file outside of the Web root. I whine and moan when I see anybody else do this, yet I was hoist on my own petard.

    Ovid's Law of User Interfaces

    No matter how well thought out the interface, if it confuses the user, it's a bug.

    In tilly's homenode, he provides a link to the the Interface Hall of Shame for Lotus Notes. I have had the, um, pleasure of working with this piece of crud. One of the "features" of the program is in the email portion. To save space, copying any email to another folder does not copy the email. It creates an alias to the original email. Deleting either the original or the alias results in both being deleted. I can't even begin to tell you how many times I heard language that would make George Carlin blush when people discovered this "feature".

    One of the curious side effects of this is that whenever I received email from a coworker, it would often be copied back to themselves. Thus, they could delete their "sent" mail safely, since they couldn't copy important sent email to another folder. Read the Hall of Shame link. It's hilarious. What's worse is the "defense" given by many of the Lotus Notes developers. Invariably they scream that the users needed to be trained. While admittedly, Bloatus Notes is much more than an email client and any company that uses it solely for that purpose is wasting their money, users shouldn't need to be sent to a training class for something as trivial as email!

    Update: Just gotta add this. In case you're not entirely sure what Lotus Notes is, here is how the developers describe it:

    • a sophisticated non-relational database environment
    • document-based-development-platform-with-integrated-mail-features
    • an applications development environment for tools that facilitate the open exchange of information between geographically dispersed individuals
    • a workflow application
    • a workflow collaboration software [sic]
    • a distributed client/server development and deployment environment
    • a database-manager

    Now, that clears things up, right? :)


    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

      Just to back up Ovid (like he needs it) developing for Notes/Domino is what pushed me into perl- "There HAS to be a better way. . ."

      I remember there was this 700 pixel HR tag that I wanted to change in Domino- I found where it was created in the nsf, changed the pixel width- AND THE WHOLE DATABASE CRASHED PERMANENTLY. It had to be restored from backup, and needless to say, further attempts were unsuccessful, and the HR never got changed.

      Gotta love having near-complete control of your web apps, without getting too into the muck, like perl affords you.

      -Any sufficiently advanced technology is
      indistinguishable from doubletalk.

        Holy cow! That is so not the way to alter images. You edit stuff by using the designer client or via one of the APIs. You got what you deserved mucking around in the raw NSF file.

        Fun Fun Fun in the Fluffy Chair

Re: Programming Laws
by mirod (Canon) on Jan 24, 2002 at 20:01 UTC

    I discovered those very early in life:

    Mirod's Principle of Certainty
    If it has not been tested then it does not work

    Corrollary to Mirod's Principle of Certainty
    Even if it has been tested, chances are that it is still bugged

      Metadoktor's Law of Spelling

      If it can be misspelled, then it will be misspelled.

      For instance, that's Corollary and not Corrollary.

      Spelling applies to programming and not just English or whatever other language you know.


      Metadoktor's Law of Documentation

      There is no such thing as well documented code.

      and a corollary...

      No one will read the documentation even if it exists!


      "The doktor is in."

        My group now has to spell "deprecated" as "depricated" because when I did the database design, I spelled it wrong, wrote a bunch of code around it, and now it has too much inertia to fix


        If it can be misspelled, then it will be misspelled.
        Big words coming from someone named "metadoktor".
Re: Programming Laws
by FoxtrotUniform (Prior) on Jan 24, 2002 at 21:41 UTC
    • Lubarsky's Law of Cybernetic Entomology:
      There is always one more bug.
    • Matt's First Law of User Interaction:
      What's obvious to the programmer will not be to the user.
    • First Corollary to MFLoUI:
      You haven't made it obvious enough.
    • Second Corollary to MFLoUI:
      The program's testers will ask the dumbest questions you can possibly think of.
    • Matt's Second Law of User Interaction:
      Users are evil incarnate. They will break your code, overrun your buffers, circumvent your error checks, and make it your fault.
    • Corollary to MSLoUI:
      Test your program with tame users first.
    • Matt's Third Law of User Interaction:
      Users will not be happy with your program unless they can make it behave like the program it replaced.
    • Corollary to MTLoUI:
      Every interactive program should admit, support, or include vi-like movement keys.
    • Matt's Axiom:
      The maximum amount of fun you can have writing code is inversely proportional to the code's immediate user base.
Deployment Laws
by clintp (Curate) on Jan 24, 2002 at 22:58 UTC
    • Never deploy software on a Friday.
    • Never deploy software just before quitting time.
    • Never deploy software just before lunch.
    Quality Control
    • Always backup the production code on the servers before updating it. Even with source control, and strict CM, you can't go home again.
    • The old software had bugs, the new software has bugs. Anyone who says differently is selling something.
    • Make sure someone else knows what you did and when you did it verbally. Chatter spreads faster than memos, and people listen to gossip.
    • Invite others to watch.

      To add to deployment

    • Don't schedule a vacation to begin right after a release.
    • I've seen too many people have to reschedule plane tickets, etc... because somebody pushed the release back a week or two. Of course, if you can don't schedule a release around important personal dates; anniversaries, birthdays of SOs, etc...

        The old software had bugs, the new software has bugs. Anyone who says differently is selling something.

      Or smoking something....


      AMEN on deployment timing:

      (Enter NARRATOR) Our CEO was hounding us in the dev team to deploy our code and completely changeover the system to rid ourselves of using our estranged partner company's code and servers, and to keep our clients quiet. And so it is here that we lay our scene.

      (in darker voice) But nobody prepared for the worst. (CHORUS sets ominous tone)

      (Enter HEROES, facing audience) My coprogrammer and I had made it known that we were to leave early for a festival three hours away in Houston for the weekend. It was a friday. And the senior developer was on a sudden family-emergency flight to California....

      (Enter VILLAINS, lurching toward HEROES) The company who was partnered with us allowed us to use their systems until we got ours set up and running. At least that's what the lawsuit settlement dictated. But they did what was completely expectable and not unthinkable: they cut us off a month too soon.

      (VILLIANS lunge at HEROES. CHORUS erupts in loud cries of jeering laughter)

      (HEROES unsteadily parry attack) After spending all day fielding calls from irate clients, panic-ridden CEO, the question-mongering call center, and with us hounding our Sr. Dev for remote assistance and advice, we got our code deployed as fast as possible and got it barely limping along to survive for the weekend. Criminy!

      (VILLAINS fall to stage and exhuent, crawling rear left) My coworker and I left long after sunset, about seven hours late, long after it started raining in biblical proportions. What would've been a happy 2.5 hour drive became 4. (CHORUS expresses deep sorrow)

      (HERO sighs and takes forceful stance) So, yeah, you're damn right I kicked back a few bottles of Guinness once we got there. Sheesh!

      (Re-enter NARRATOR) So, friends, it is with these events that we affirm the wisdom of the ages, expressed as this:

      Shawn's Law of Discriminated Determinancy: The determined effort to enjoy life, leisure, and absolute programming grace will be prejudiciously discriminated against and undermined by external forces beyond all sovereignty and control.

      -Shawn - (Ph) Phaysis ... --- ...

      Always backup the production code on the servers before updating it. Even with source control, and strict CM, you can't go home again.

      I can't tell you how true that point is. Our release program automatically makes a backup of the old code (places it into an archive dir actually). That way we can easily swap back to the old version if something unexpected happens.

      Oh and I know you wrote this 14 months ago but I've only just read it :-) Hey, better late than never right...

      -- vek --
Re: Programming Laws
by moodster (Hermit) on Jan 24, 2002 at 20:37 UTC
    "No matter how thorough you test your application, when you make your first live install at the customer's site, it will break."

    No, really. It will break. I've been there so many times that I tend to take it for granted by now.

    -- moodster

Re: Programming Laws
by neophyte (Curate) on Jan 24, 2002 at 20:10 UTC
    If any piece of code (aka program) has
    • at least one superfluos line and
    • at least one bug (as stated elsewhere on this site),
    the ideal program has 0 lines and 0 bugs.
    But still bosses and customers will complain if you deliver a program like that.


Re: Programming Laws
by tadman (Prior) on Jan 24, 2002 at 21:40 UTC
    From The Soul of a New Machine:
    "Not everything worth doing is worth doing well."
    Which is part of the "Laziness, Impatience and Hubris" principle, or perhaps the "Worse is Better" theory of software development.
Re: Programming Laws
by chromatic (Archbishop) on Jan 25, 2002 at 03:56 UTC
    No matter how clever, experienced, or lucky you think you are, you are always one shortcut away from feeling really stupid.

    (Not that I just copied a test template over a finished test or anything. :)

Re: Programming Laws
by blakem (Monsignor) on Jan 25, 2002 at 00:38 UTC
    Earlier this week when pressed for a Perl 6 development timeline, Larry Wall gave us this little gem:
    "Never predict major software releases within 6 months of the end of the year... in either direction."
    I'm not sure if its an original Wallism, or just a joke he was passing along. ;-)


Re: Programming Laws
by stefp (Vicar) on Jan 25, 2002 at 00:10 UTC
    If you omit parentheses, the operators do not have the relative precedence you expect. If you do parenthese defensively, you get flamed because you confuse Perl with Lisp.

    -- stefp -- check out TeXmacs wiki

Re: shadox Programming Laws
by shadox (Priest) on Jan 25, 2002 at 21:30 UTC
    • No matter how hard you search, no matter you ask everyone,
      as soon as you finish that killing piece of code, someone who was
      next to you all time, will tell you "Hey.... i have some code that do that"
    • You can work all day, stay late at night in the office, and you won't find that bug,
      until you are in the road to your home
    • If you make your program in a server, when the program is ready and your client wants
      to download it, there will be problems with internet or the server will be down.

    Dreams they just disapear into the shadows,
    then they become true....

Re: Programming Laws
by gt8073a (Hermit) on Jan 25, 2002 at 13:56 UTC
    $vacation->subtract_quality( $_->has_obvious_fix() ? $_->get_severity( +) * 100 : $_->get_severity() ) foreach grep{ !$_->is_existing_problem +() and $_->get_contact() eq $me and $_->get_description() =~ /a docum +ented feature/i } @{$work->get_bug_list()}

    Will perl for money
    JJ Knitis
    (901) 756-7693

Re: Programming Laws
by Sonnik (Initiate) on Jan 28, 2002 at 21:41 UTC
    no matter what YOU think your code does , the salespeople, your boss and your coleagues have their own ideas about what your code's use

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://141227]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (3)
As of 2024-04-14 11:31 GMT
Find Nodes?
    Voting Booth?

    No recent polls found