Some timeless IT/tech jokes, and why they’re still relevant

If you’ve been in the information technology industry for a number of years, certain jokes tend to pop up again and again. Why? I’d say it’s because their underlying premises, the things that make them applicable and funny, continue to occur. So even if you’ve heard these before (and that’s probably the case), it’s worth taking a few moments here to look at them again and consider what makes them timeless.  Remember, even jokes have morals to the story. Sometimes especially jokes.

1) Just what they asked for but not what they want
Something that’s been drifting around the Internet for decades, it seems, are various IT versions of the famous poem, “Twas the Night Before Christmas,” usually called “Twas the Night Before Implementation.” I won’t include the whole text here; most notably, the poem ends with the “super programmer,” akin to Santa Claus, swinging into action and saving the day.  And yet, the final two lines read,

And the user exclaimed with a snarl and a taunt,
“It’s just what I asked for, but not what I want!”


Who in IT can’t relate to this eleventh-hour disconnect between what the user “wants” and what IT has arduously created and delivered? Why does this phenomenon keep happening? A lengthy serious answer here would derail the intended levity of this post, but consider the following:  the long-standing industry practice of pure, unadulterated “waterfall“-style requirements gathering before design, build, test and deliver tends to lead to such disconnects. That fact certainly presents an argument for greater agility in the process, greater involvement of stakeholders throughout, and resistance of “big bang” approaches to systems delivery.

Two Texans are talking:
–Why, I can git in my pick-up, start at one end of my ranch in the mornin’, drive all day, and not git to the other end till sundown!
–Yep. I had a truck like that, once.


This joke almost always comes to mind whenever I hear IT people blissfully bragging about the complexity or size of their infrastructure, latest system, etc.  For example, most recently, my friend Gunner was telling me about his current development project, just entering User Acceptance Test: “Our programmers have gotten a total of 8 hours sleep in the last three days!”  “Yes, Gunner,” I replied. “I had a truck like that, once.”

Size, complexity, and lack of sleep are sometimes unfortunate realities, but they are rarely great things to brag about.  Don’t let your enthusiasm for what you’ve accomplished make you forget that simpler is nearly always better than more complex, smaller almost always better than large, and sleeplessness leads to bad decision-making in the trenches.

3) What you just told me is technically correct but of no use to me whatsoever

A man piloting a hot air balloon discovers he has wandered off course and is hopelessly lost. He descends to a lower altitude and locates a man down on the ground. He lowers the balloon further and shouts “Excuse me, can you tell me where I am?”
The man below says: “Yes, you’re in a hot air balloon, about 30 feet above this field.”
“You must work in Information Technology,” says the balloonist.
“Yes I do,” replies the man. “And how did you know that?”
“Well,” says the balloonist, “what you told me is technically correct, but of no use to anyone.”
The man below says, “You must work in management.”
“I do,” replies the balloonist, “how did you know?”
“Well,” says the man, “you don’t know where you are, or where you’re going, but you expect my immediate help. You’re in the same position you were before we met, but now it’s my fault!”


Rackspace, a prominent managed hosting provider, recently incurred a massive outage. Even though this is a company that prides itself on “fanatical service,” (and to be sure, is praised by many of its customers for providing such), on the day of the outage, it sent out a “customer incident report“, featuring sentences like, “The generators experienced a subsequent excitation failure forcing transition of cluster A back to the primary utility feed prior to the completion of UPS repairs.” Rackspace’s incident report is an amazingly bad example of jargon-laden, un-customer-oriented IT communication. There’s no discussion of real root cause (the breaker tripped, but why?) or specified action plan, just a bunch of seemingly nervous technobabble that lets no one understand what really happened, why it happened, and what they’re doing to ensure that it won’t happen again.

In other words, everything in their report is technically correct, but it’s no use to anyone. Sure, they were still in the throes of diagnosis, but that doesn’t excuse the plethora of excess detail and their failure to address what customers really are interested in. This kind of approach inspires negative confidence among one’s customers, needless to say.

4) Difference between a methodologist and a terrorist
This joke has also been around for decades. I stopped telling it for a few years after 9/11, but it continues to make a needed point:

What’s the difference between a methodologist and a terrorist? Answer: you can negotiate with a terrorist.


I’ve frequently noted that some IT folks latch onto a particular methodology (Rational, Agile, Lean, whatever) and come to see it (and it alone) as representing pure, unvarnished guidance and truth.  If not brought back to earth, they can drift into a discipleship attitude that there’s really only “one true way” of approaching systems and projects.  If confronted with a failure in a project using their “one true way,” they’re quick to claim that the methodology wasn’t fully or correctly implemented (“If it doesn’t work, you aren’t doing it right.”).  This “one trick pony” perspective, a sort of tunnel vision that lacks introspection, creates a rigidity that’s almost always detrimental.

In fact, it tends to put you into situations where joke #1 is relevant.

 

Lagniappe: 

 

Comments

  1. Peter,
    Very funny and so true. I forgot about #4. But it is still relevant. Thanks for sharing.

  2. Number 4 caused me to recall a past employer where, a few years back, a technology group jump on Agile and completely fulfilled your discipleship description. Needless to say, they burned bright but quickly faded. What ultimately caused them the most challenge was agilely developing their infrastructure … you can’t keep swapping OS’s and application server platforms as business requirements change with taking on huge costs and delays.

  3. IT, IS, et. al., have always been their own worst detractors. In my 35 years of IS&T Leadership, I have fought the notion and impression that IS&T are a bunch of hackers located somewhere in the bowls of the boiler room – who never come into the light.

    The trick is two-fold. One, to get senior management to recognize the value of bringing IS&T to the table and two, while at the table, don’t spill your soup. The most successful CIO’s are the ones who come from business… because, unless the company produces or services technology, they are not interested in it, other than it’s value to the organization.

    Try putting a tie on your crew and getting them out of the server room – into the business light. Communicate business goals and motivate them to think outside narrow IS&T parameters and instead from the customer’s business need perspective.

    Stop presenting IS&T as a bunch of broken-glasses geeks, and you will be astonished at the positive impression the business will adopt of technology.

  4. I enjoyed your post and very well written. I didn’t realize that Rackspace was so good with customers service.
    Also, i like the way you weave the jokes into the post.
    Thanks – Bill

Trackbacks

  1. […] In fact, I regard the publication of uptime metrics like that as a regrettable symptom of IT focusing on technical aspects, rather than business impacts.  Here’s a discussion of why I see it that way, followed by a […]

  2. […] la publicación de indicadores como el tiempo de disponibilidad, como un síntoma lamentable de que TI se centra en los aspectos técnicos, en lugar del impacto en el negocio. Aquí hay una discusión de por qué yo lo veo de esa manera, […]

  3. […] of my most visited blog posts noted that certain IT jokes tend to come up again and again. That post covered four such familiar […]

Speak Your Mind

*