Top 12 Things Likely To Be Said By A Klingon Programmer

found originally at  Courtney Hentz (CHentz@spinner.com)

1. Specifications are for the weak and timid!
   
2. This machine is a piece of GAGH! I need quad PowerPC processors if I am to do battle with this code!
   
3. You cannot really appreciate Dilbert unless you've read it in the original Klingon.
   
4. Indentation?! I will show you how to indent when I indent your skull!
   
5. What is this talk of `release'? Klingons do not make software `releases'. Our software `escapes' leaving a bloody trail of designers and quality assurance people in its wake.
   
6. Klingon function calls do not have `parameters' - they have`arguments' - and they ALWAYS WIN THEM.
   
7. Debugging? Klingons do not debug. Our software does not coddle the weak.
   
8. I have challenged the entire quality assurance team to a Bat-Leth contest. They will not concern us again.
   
9. A TRUE Klingon Warrior does not comment his code!
   
10. By filing this bug you have challenged the honor of my family. Prepare to die!
    
11. You question the worthiness of my code? I should kill you where you stand!
    
12. Our users will know fear and cower before our software! Ship it!Ship it and let them flee like the dogs they are!
    

Shoot Yourself in the Foot!

!WARNING! If you're not a major nerd or geek you won't get these jokes!
Recently a friend of mine sent me some funny additions to the Shoot Yourself in the Foot! list. The list is a humours look a the logic you might need to "shoot yourself in the foot" in different programming languages. Here are his suggestions:

Python
You try to shoot yourself in the foot, but the gun refuses
to go off because it doesn't have appropriate space around it.

Perl
You quickly create your own gun and shoot yourself in the
foot. Witnesses are unable to explain what happened. No one else can
figure out how to use the gun.

JavaScript

Your prototype gun admirably shoots feet during testing,
but in production many users' hands are incompatible

Flash
As you pull the trigger, the gun's barrels surge
impressively to life. The muzzles flash, smoke billows, and the ring
of pounds of expelled brass is barely audible over the deafening
gunfire. After the smoke clears, your foot is unaffected and you
realize nothing seems to have happened.

Here are a few of my own additions/revisions:

Visual Basic 6
You take advantage of the very handy ShootMyselfInTheLeftFootOnce() method and wait three years for M$ to release a ShootMyselfInTheRightFootOnce() method.

C#
You spend several hours browsing through Intellisense drop downs and the object browser looking for the right combination of .Net classes and methods to shoot your foot and eventually decide to port the Java libShootMyFoot library.

Java
You decide to take advantage of the libShootMyFoot library. After days of scanning painfully abstract API documentation you realize that, through some complex twist of logic that still can only be understood by developers working for Sun, the libShootMyFoot library was never intended to be used for shooting feet.

Please post any additons you would like to see!

New Pattern: CPT (Can't Polish a Turd)

I recently read a hilarious article, "Asshole Driven Development." The author, Scott Berkun, takes a cynical look at the abundance of acronyms in the software engineering field. Along the way he uncovers a few insights that, while very cynical, ring true. In addition to Scott's funny acronyms many users have added additional goodness. One anonymous post read:

How about CPT (Can’t Polish a Turd) development, This is where management cannot understand the need to stop and fix/clean up/refactor or start again.

I saw this post and wondered if we hadn't worked together! I've polished many turds in my time, a few were my own, and let me tell you...it's not easy. The fact is, these turds never really shine. Sure, sure...wet em down a bit...put em in the right light and they seem to shine. Heck...we have well paid people (some brilliant) that spend most of their time putting turds, in the right light. But, in the end a turd by any other name is still crap.

So why all this infatuation, with turds? In my experience it can be broken down into several very bad reasons:

• Turd Love Affairs: This turd was once your next big thing. It would solve all the world's problems and make the company tons of cash. Somewhere along the line it got off track for various reasons (see the above article) and no one wants to admit it. These love affairs can be identified by an organization's death march development of a product that almost no one likes.
  
• WSIA (We Sold It Already): WSIA is a surprisingly common problem. It's in the field and someone has paid for it. Because it's a turd it takes all your manpower to constantly tweak and thus no developers are available to work on a new version or refactor the old turd. Companies with this problem are usually immature and don't adequately plan for the software's lifecycle. (BTW: XP solves this problem since it assumes the software is never done)
• Management Mistrusts the Engineers: I imagine them sitting around in a smoky room saying, "well those stupid nerds are whining about the XYZ again. Tell them we'll start on the new version in a month...that'll shut them up." Of course that month becomes 3 then 6 then the project is scrapped or the company goes out of business. "What!? no one wanted to buy a shiny new turd?!"

So, what can we do when we find ourselves in this situation? The first thing I always advise when someone feels workplace dissonance is to step back and remember, "everyone in the organization is probably doing what they think is the best thing for the product." This is important because we have to know that our peers and those above us are trying to make the project successful. People aren't always going to agree on the best plan of action.

The first thing you should do is try to understand why the organization is doing what it does....polishing turds. In most cases you just need to look at the project from another person's perspective. How long have they been working on this project? How emotionally attached are they? What fears do they have of losing customers? Once you understand the reasons for polishing turds you can begin to form arguments that support your course of action.

Finally, most turds started out as great ideas. Many of them can be fixed or re-written. Look for that original, good idea. In this way the true brilliance of the original great idea can shine through!

You can probably think of more reasons companies shine there crap...feel free to post a comment.