ColdFusion Muse

War Room Troubleshooting and "Reaching Out"

Network and Power cables were strewn everywhere. Laptops littered the large table top. A conference bridge was constantly open and provided access to outside individuals interested in the outcome. A team of 10 or 12 people surrounded the problem like a group of hyenas closing in on a hapless gazelle. It was part of a troubleshooting effort at a large client site this week. I sat in on the "war room" and offered help in the area of Coldfusion server configuration and optimization. The system in question was a complex amalgam encompassing a JMS system, an AS/400, CFMX 7, an FTP server, and multiple database servers. Folks from networking, database administration, server administration, development, customer service and business analysis were all in on the battle.

As a technique for attacking an entrenched issue it was effective. All the people with a stake in the outcome were in the room or connected to the bridge, and all the folks with the necessary knowledge were putting their heads together at the same time. It was an effective way to mitigate the "blame game". You probably know about the blame game. A problem arises and the main issue becomes how to effectively avoid ownership of it until someone is "forced" to take it by the horns. The blame game results in too much trial and error, and too much “serve and volley” - with stakeholders sitting back and hoping the ball doesn't end up back in their court.

In the war room however, individuals with the knowledge to dispute assertions were readily available. When a possibility was raised the resources necessary to check its validity were right in the room. Of course such a situation is pretty drastic and expensive. It requires interrupting the schedule of busy and important people and "forcing" them to focus on a problem until it is solved. Generally such people are used to being trusted and not used to anyone cross-checking their assertions. Tempers can flair and arguments ensue. Still, if the problem is bad enough and the session is necessary, it can be effective as a way of troubleshooting - especially a complex system with multiple external resources.

In our case we were able to observe the situation in real time from several viewpoints and a consensus viewpoint finally emerged as to the source of the issue and it's possible resolution. The main problem in this case was the fact that the program in question uses a message queue synchronously instead of asynchronously. In other words, the same request depends on both the request and the reply. This is analogous to using JMS as if it were a database - and it's counter intuitive to the way a "queue" is designed. I'll get more specific in another post.

Reaching Out

I'm quite sure this comes from a book I've never read, or perhaps a motivational speaker that would induce me to put my head in a large vice (It's either the vice or the ice pick in the eye) but when did the term "reach out" come into vogue? In this recent session, no one "called" and no one "emailed". Instead, everyone "reached out" to everyone else. It was almost as if the word "call" or "email" was considered impolite. The goal I suppose was to be personal and collaborative. Let's "reach out" to that customer and see if we can solve this issue, or have you "reached out" to network support for help?

While I'm all in favor of using careful language to help us maintain the right attitude, it was obvious that these folks had been using it so long it was simply a euphemism for "call" or "email". Sitting in my chair it became a little comical to listen to the conversations around me. One person said (and I quote - as nearly as I can remember):

It's safe to say that the power behind the idea of using "reach out" instead of call has lost some of it's vitality. Now if you will excuse me I have to reach out to my mechanic. My car is in the shop and he has failed to reach out to me yet.