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,
“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.
–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
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:
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:
- Follow-on post: More timeless, still-relevant information technology jokes
Peter,
Very funny and so true. I forgot about #4. But it is still relevant. Thanks for sharing.
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.
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.
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