Programming Laws

[dreadpiratepeter]

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>


-pete
Entropy is not what is used to be.

[Ovid]

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? :)

Cheers,
Ovid

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

[Hero Zzyzzx]

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.

[diotalevi]

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

[mirod]

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]

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.

also

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!

metadoktor

"The doktor is in."

[scain]

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

Scott

[boo_radley]

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

Big words coming from someone named "metadoktor".

[FoxtrotUniform]

• 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.
--
:wq

[clintp]

Timing
• 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.

[lemming]

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...

[FoxtrotUniform]

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

Or smoking something....

--
:wq

[Phaysis]

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 - (P^h) Phaysis ... --- ...

[vek]

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 --

[moodster]

"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.

Cheers,
-- moodster

[neophyte]

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.

neophyte Niederrhein.pm

[tadman]

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.

[chromatic]

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. :)

[blakem]

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. ;-)

-Blake

[stefp]

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

[shadox]

• 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....

---

[gt8073a]

$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
[phone]
[e-mail]

[Sonnik]

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