Assumptions versus Observations Part 2

corporate authenticity,blogging,Adobe RoboHelp,cluetrain manifesto

Part 2: Assumptions versus Observations | Jetman’s Bent Pins Philosophy

Let’s tell a hopefully compelling story about how I view the matter of simply assuming things. This might explain to some why I looked at the RoboHelp details so closely.

When I was in military aviation, we were taught if we assume something eventually that assumption would kill us.

Like the pins that held the parachute in place in my Escapac ejection seat.

In nearly a thousand hours of flight time I always checked the pins on the back of my Escapac ejection seat parachute. If one of those pins were bent and I had to eject, the parachute designed to save my life would be rendered into a ninety pound silk (well, nylon) brick, helping me only to achieve terminal velocity rather than obtaining a relatively safe descent.

I found bent pins in my ejection seat only twice. Both times I brought this to the attention of the parachute riggers, devout professionals in all things survival related, who replaced the chute prior to the flight.

One of those two bent pin flights was a hotseat flight, the jet had just landed and we swapped crews out while the engines turned at low speed on the deck. This meant the aircrewman who had just left the jet had not checked those pins. He had hosed up his preflight which could have killed him. Or killed me if I had assumed that his preflight was done properly.

We had a discussion about it after I landed. It was pretty one-sided as you might well imagine.

After all, I didn’t assume everything would be fine and dandy. I might have needed that chute.

But hey, if I flew with the bent pin chute and nothing bad happened requiring an ejection, it wouldn’t matter, right? Think about that for a minute. A lot of things have to go wrong to require an aircrew to abandon their jet. Philosophically reflecting, I wouldn’t need that chute unless the rest of the day became very very bad.

Let’s talk about a very very bad day. One in which that ejection seat might have come in really handy for me.

Operating on Assumptions: A Case Study of Military Aviation

My worst bad day was returning from a training mission off the coast of San Diego (Whiskey -291 Op Area for those in the know) and having to attempt landing with unsafe gear, two five hundred pound bombs ‘hung ordnance’ (meaning fully armed and not dropping when the button was mashed) in the bomb bay, the bomb bay doors mostly open, and the flaps stuck in.

While my story is titled A Bad Day, check out NeptunusLex’s Worst Day Ever for a real Naval Aviation horror story.

Hung Ordnance: This means the bombs were ‘pickled’ but didn’t fall off the jet. Sometimes hung ordnance just explodes.

Boom.

You never feel a thing. But that would be if the arming wires got pulled out, and your luck ran out and the detonator triggered. The safe way out of this mess is the duty Explosives Ordnance Disposal (EOD) team which comes out and renders the bombs safe in some sort of arcane black magic way.

Flaps stuck in: that meant we had to take an arrested field landing, dangerous in itself because the cable could snap, we could get caught up in it and flip over, or we could just not brake in time and go off the end of the runway.

if we survived that, the bombs had to stay attached, otherwise they’d either fall and pull the wires arming the bombs which, .24 seconds later would be primed for detonation on impact.

Bomb Bay Doors: the bomb bay doors, if closed, would prevent the bombs from falling far enough to arm. Since the bomb bay wouldn’t close all the way this compounded our already big problem.

The bombs could, as we arrested on the cable during landing, pop out and skitter down the runway. This would become the crash crew’s problem as they would be rolling to meet us.

Or they could become everyone’s problem because at the end of this runway was the fuel depot.

Unsafe Gear Down: That means that once weight was put onto the gear, it could collapse. We all see commercial jets now and again that get wonked onto a runway and everybody slides to safety. Whee! In the military, someone who knows what they are doing has to pin that gear so if the landing gear fails, the pins catch it.

If we landed and survived the arrested landing without running out of runway, someone would have to jump out and pin the landing gear, because at any time without the 3/8" pin in the gear, the unsafe gear could collapse, on one side, both sides, or the nosewheel gear. This collapse could kill whoever was outside underneath the jet at the time. Or not only kill that person, the bombs could fall off the jet and kill everyone within the frag pattern - about a mile.

Before we landed, we flew in circles around Naval Air Station North Island until we burned most of our gas. I watched the sun go down for what could have been the last time. During that time, we talked about ejecting rather than landing. We all had a vote - all four of us.

We all decided to risk the landing even though everything had gone wrong except for lightning striking us or an engine falling off the aircraft.

I was the one who had the job of unstrapping and jumping out of the jet to pin the gear. If we survived the landing, if we were able to not run off the end of the runway, and the bombs didn’t go off, I could be lucky enough to be crushed underneath that 30,000 lb aircraft while I was pinning the unsafe gear.

So. I have to ask you, are you the type of person who would assume the unsafe gear would hold, and not pin the jet? Would you assume that the bombs couldn’t detonate and refuse EOD’s help?

Would you fly a combat mission with a bad parachute? Would you land, and taxi back with hung ordnance without pinning the gear?

I’m not the type of person who would. By the way, the types of people who would operate on assumptions in Naval Aviation… Never made it through the training program.

Assuming was treated the same as missing something. Missing something critical was grounds for a Signal Of Difficulty (SOD). One SOD in safety of flight meant an instant failure. Two SODs, pilot, flight officer, or aircrewman, and you were answering hard questions for a board of your instructors who would decide your future.

Nobody every got three SODs and still flew. Because at the end of the day, each instructor had to realize that they would stand a chance of their life depending on this individual at some future point in time. I never got a SOD by the way. Kinda proud of that.

I have six of my friends who assumed things during training and ended up with a vastly different Navy Adventure than I did. They ended up loading bombs onto jets, or refueling jets rather than flying in them.

Assumptions killed their career in training before it ever began. Observations, and acting appropriately through my training and judgement, gave me some of the best experience and best friends I’ll ever have.

By the way, to wrap up the story. I lived.

I lived. Because my team got their jobs done, and our technical support got their jobs done when we had problems.

Clearly this is not on the same level as the software. Or is it?

In fact, the teamwork required to get that jet into the air is a lot like the teamwork required to get a piece of software to work as advertised. Mechanics work like Developers, checking all the critical elements. QA is the same in aviation and in software. In my story, EOD is like Tech Support; they take care of the bombs.

Let’s say you make a software purchasing call for your technical communications department and it fails. Messily fails, like hung ordnance falling out and arming. Like the project fails right before deadline, and cannot be resurrected. In fact, even though you spend the extra bucks for maintenance, the software’s tech support team tells you, Sorry!

Boom.

Can you afford to assume that your manager won’t hold it against you? Would you assume you wouldn’t lose your job if the software you recommended couldn’t deliver what it promised?

What is the significance of RoboHelp not included in Adobe’s documentation?

This is a more philosophical question. It’s very subjective. That’s why I asked that others merely examine my raw data and draw their own conclusions.

Sarah had a very clear conclusion: That Adobe didn’t care too much about RoboHelp because it wasn’t bringing in enough money.

My conclusion is different, although her analysis did lead me to rethink some elements:

• Adobe had no initial intention of reviving RoboHelp. The Investor Relations documents don’t show intent to release RoboHelp 6, and don’t show historical data for RoboHelp X5.
• Adobe has not supported RoboHelp at the highest levels. Their brain trust of Tech Support was released, then requested to come back because they ‘made a mistake’.
• Adobe is fickle with the RoboHelp and HAT market. There is a strong push for maximizing revenue rather than investing in customer goodwill. Hence no following the previous pattern of one update every year for free, and annual product updates guaranteed for maintenance customers.
• Adobe is very interested in maintaining a profitable revenue stream, therefore will not jump into a complete code rewrite - critical for a HTML based editor to become an XML-based editor.
• RoboHelp is no longer the market leading HAT tool. Vivek didn’t answer the HATT communities direct question about his statement to this effect.

So let’s look at the HAT market data. This is admittedly dated information which should have been updated within the Adobe documents, but was left out leading to our current discussion.

RoboHelp’s Market: Help Authoring Tool Market Data

The data I recall is from the eHelp merger documents given to all eHelp shareholders in 2003’s Macromedia merger. I recall something like a $30 million / year market. That’s what - 30,000 copies / maintenance agreements per year?

That’s pocket change for Adobe, according to Sarah’s post.

Would you want to buy software from a company that, it is assumed by their actions, does not care about your needs? Or would you want to buy software from a company whose core competency and sole focus is Help Authoring Tools?

You probably know by now which direction I’m starting to lean in: I’m the kind of guy who wants a Parachute Rigger to rig my parachute, not a baggage handler. I’m the kind of guy who asked for the EOD duty team to disarm the bombs, and didn’t try it myself.

Same with my required software tools.