Busy Weekend Volunteering

As I mentioned previously, I was on vacation for about 10 days and got back to Albany very early Wednesday morning (or late Tuesday night depending on how one looks at it.) And once back from vacation I had to jump right back into two other events I had previously put on my schedule. This meant I didn’t have much time to catch up on work or sleep. But it was worth it.

A confluence of events meant that I ended up being double booked this past weekend. The first event was some special cave rescue training called a Small Party Assisted Rescue (SPAR) class. This was a 3 day class, Friday through Sunday. However, in addition, students had the chance to show up Thursday night in order to test on their skills before participating.  I was both an instructor for this class as well as the site and course organizer. My second event was SQL Saturday Albany, which I had been selected to speak at. I’m also the User Group coordinator that sponsors this event. This double booking meant that I couldn’t instruct at the SPAR on Saturday. I do want to note that at both events there were a number of other volunteers, and some were doing even more work than I was.

Between these two events, it meant I was getting about 6 hours of sleep a night plus putting in a lot of driving. It was a long, tiring, essentially 3.5 day weekend starting on Thursday. Additionally the jet-lag made it seem even longer.

Why do I mention all this? Because, both events are very important to me and cover two large areas of my life. I’ve previously written about some of my SQL Saturday experiences and SQL Pass experiences.  This is part of my professional life. I feel very strongly about volunteering and speaking at these SQL events. I enjoy running our local Capital Area SQL Server User Group (CASSUG) for the same reason. I’m a better DBA because of the shared experiences of my fellow speakers. I’ve written about this previously here and elsewhere in this blog. I hope I’ve helped others.

WP_20190720_002

Deborah Melkin discusses normalized vs. star schemas.

On the other side, as my slide deck often points out, I’m a caver. More critically I’m the Northeastern Regional Coordinator for the National Cave Rescue Commission. I’ve had the privilege of teaching 100s of people how to perform cave rescue, been a media resource during the 2018 Thai rescue, and have spoken and written on the subject. I am by no means an expert, I’m always learning, as are all my fellow instructors. But, we all are not only willing, but want to spend the time and money and effort to teach others. We are passionate about it.  I don’t mean this lightly. For this particular SPAR, while about 1/2 the instructors lived within 2 hours of the event and it was an easy drive, the rest either drove 5-8 hours, or spent all day flying on standby to get here or to get home. None were reimbursed for any of their expenses and in fact had to pay for linens if they wanted them.  They also had to take 2 days or more days off of work to come to New York.

Next summer, I will be the course coordinator for our 2020 National Weeklong here in New York State. This will bring close to 100 people to New York for a week of 14 hour days of teaching and learning cave rescue techniques. Fortunately, I will have a LOT of help organizing this event. But again, all the instructors and staff are volunteers who will travel at their own expense to be here and help teach.

So I spent my weekend volunteering, because I’m passionate about it. How was your weekend?

 

Tighter than I Remember

I’ve been reading a book off and on for about a year now called, Being Wrong : Adventures in the Margin of Error. It ties into my interest in meta-cognition and how we think.

We build a model in our head of how the world is. Often times it’s accurate, but often times it’s wrong. In my model of the world, the Sun rises in the East. This model is accurate and corresponds with the model most of us have. But I can easily construct related models that are wrong. Looking back I can remember that it was sunny on a particular day, only to find if I check the records, it was raining. My memory is wrong, but it created the model I had for that day. I can also create a model going forward. Last night, going to bed, the world I was going to wake up to was sunny. This was based on the weather forecast and the fact that the Sun rises in the East. Well, the Sun may have risen today, but it’s not sunny. There’s far too many clouds. So that model was wrong.

This all comes to mind because of a caving trip I did this weekend. There’s a fine little cave near here called Ella Armstrong. It’s really not much of a cave, perhaps 250′ of walkable passage total. But I’ve always liked it even though I hadn’t been there in 15-20 years. It’s got a nice vertical drop at the entrance that’s great for beginners. And it has an easy walk-in entrance.  As a result, I had been considering using it for some cave rescue training next year.

So you can imagine my surprise when two of my fellow cavers who had been there just a few weeks ago said I was in fact wrong and it’s not a walk-in entrance and that in fact it’s rather tight. I was surprised. I didn’t really doubt them, but figured perhaps we had a different definition of what we considered a tight entrance.

Now, let me take a little detour here and mention that almost every caver will at some point joke about how a particular cave has gotten smaller over the years. It’s a little lie we tell ourselves to account for the fact that many of us have put on a few pounds since we first started caving and some passages are in fact harder to get through.  The truth is, rarely due caves get smaller, though sometimes passages sometimes do get larger. There’s a cave in Vermont where I’m pretty sure fitting through 2 of the 3 tightest spots is probably close to impossible for me now. And I know the cave didn’t change sizes, so I’ll have to admit I have.

But back to Ella Armstrong. If you had asked me to describe the entrance prior to this weekend I’d have described it as about 12′ tall at its tallest and 3′-4′ wide most of the way to the top of the drop.

Well, as Saturday proved, the model in my head was only half right. The map lists the entrance as 8′. I’ll call that close enough to 12′ since it simply means there’s no chance to hit my head on the ceiling.

On the other hand, most of the entrance from the surface to the top of the drop is NOT 3′-4′ wide. It probably averages 18″ at most and in parts is just wide enough for me to work my chest through with some contortions. My first reaction when I got to the entrance was, “perhaps some rocks have fallen in and narrowed this from what I remember.” But, after I started to scramble beyond some of the rocks on the surface, I got to the bedrock, which I know hadn’t moved and realized that my model was dramatically wrong. It was tight enough that at one point I considered calling off our trip. It wasn’t that I didn’t think I couldn’t make it further down and past a particular spot; gravity would see to that. It was more that I was afraid I might not get back UP past that spot. Finally after some mental gymnastics I figured a way I could not only get down past the choke point, but felt comfortable thinking I could get back up past it. As I’m writing this from the comfort and safety of my home, you can see my mental gymnastics worked.  Actually, it turned out the crux move on the way out was a bit further up that wasn’t nearly as tight, but had a short shelf about 3′ up in a spot that wasn’t great on foot or handholds. On the way in, that spot didn’t appear to be an issue at all. So again, in the narrow space of about 20 minutes my mental model failed me.

The truth is, we make mental models all the time. It’s how we operate in the world. But sometimes those models are wrong. Sometimes in a positive way, the tight spot getting out wasn’t as bad as I thought, or in a negative way, the spot I thought would be easy, was in fact the hardest sport. But regardless of the errors in many of our models, we generally navigate the world in a successful manner. Being wrong isn’t necessarily the end of the world.

Unfortunately though, as much as I love this cave, it really is too tight to be practical for cave rescue exercises. Which is a shame, because it is a great little cave. And if you’re ever in the area and want to check it out, let me know. I’d love to take you. But I’ll warn you, it’s a bit tight in spots!

Being Observant

I was busy last week teaching cave rescue at the annual National Cave Rescue Commission Weeklong training seminar, hence my lack of a post last week.

As always, I had a great time helping to teach a class of 19 students. Our teaching includes classroom time as well as time in the field. We use both caves (obviously) and cliffs for out in the field instruction. The cliffs give us an opportunity to focus on rigging and lets everyone see what’s going on; mostly. In a cave, often it’s too dark and small to let everyone have a good few.  But, you may notice that I said mostly above.

Let me interrupt with a quick video.  Can you count the number of times the players dressed in white pass the basketball? If you got 15, congrats.

Now back to the class being on the cliffs. As part of our exercises, we usually do several iterations of the same thing, such as lowering a patient and then raising them up. Each time we may change a detail or two, such as where they can rig, what haul system to use, etc. The idea is that repetition helps them learn the skill. Often though, at the last iteration we toss in a wrinkle: they’re not allowed to speak, at all. Generally this means, they have to start with a pile of rope and hardware on the ground and without saying a word, rig a safe system to lower and raise a patient.  Generally they use a variety of hand signals and various body motions. While at times it can be quite entertaining, it can also be instructional. It’s often the faster iteration of the day, in part because they’ve honed their skills but also due in a large part because there’s no ideal chit-chat.

The point of the exercise is multi-fold. Partly it’s a great challenge for them that they end up really enjoying. It also illustrates that communication is still possible when you can’t verbalize things. This is actually often common in caves where rushing water or echos can make vocalizations useless. It finally shows that they’ve come together as a team and can work effectively.

That said, sometimes they can miss details. As instructors we ensure though that no safety issues are missed. We will stop the exercise if we see something unsafe and help them make it safe.  Part of this includes an instructor on a separate rope to hang over the edge so they can watch the patient (generally another instructor) go down and come back up. This instructor watches the entire process for safety reasons.

This time around, we decided to add a bit of a twist to the exercise.  Generally the safety instructor stays at the top. This time however, he rappelled over the edge, all the way to the bottom. Nothing overly unusual about that.

However, once he was at the bottom, along with the patient, who happened to be me, I very quickly detached the ropes connected to my harness and connected them to his harness. I then moved over to the line he had been on and started to ascend as the students began to haul him up.

They eventually got him to the top and congratulated themselves on a job well done. Other than the student at the edge of the cliff who had watched the process, none of them appeared to notice that they had lowered me and raised him.

This actually isn’t totally surprising. We like to think of the human brain as a computer, but in many ways it’s not. Or at least it’s not a digital one with perfect recall. We actually ignore a lot of “noise” in order to focus on what’s important at the time. The fact that the person they hauled up was different from the person they had lowered counts as noise in this case because it’s so improbable that the brain won’t bother processing it, lest it take away from more important tasks, like ensure the ropes were handled safely.

And for those of who you didn’t watch the video, the answer is 15, but that’s not what’s important. Go watch it.

Today’s takeaway, our brains are fuzzy and work “well enough” most of the time, but can miss details. And generally, that’s ok.

Too Many Tabs Open

It’s been one of those “busy-slow” weeks. I get these sometimes when I’m consulting. On one hand I’m busy, but work is slow. What do I mean? Well Monday I was on a train all day (literally other than a 1.5 hours layover in NYC) coming back from Atlanta. That’s another story but suffice to say, I wasn’t much in the mood to get work done. Tuesday, when I generally write this blog, I had a couple of customer meetings and was busy, and then the rest of the day busy with non-client work. Same with Wednesday and Thursday.

Finally today, I had a few minutes to catch up on some stuff. I FINALLY took the time to look at one of the tabs I had open in my browser. Admit it, you do it too. “Oh look, that’s cool I want to read/watch/listen to that, but not now, I’ll just keep that tab open.” And then weeks later you’re like, “what is this tab?”

In this case it was a video post by Grant Fritchey on “Why friends don’t let friends upgrade to SQL 2014.”  I was curious about this because at a client I had to recently upgrade two servers to SQL Server 2014. I had preferred SQL Server 2016 or 2017, but the 3rd party software vendor said “no”.  Fortunately nothing bad has happened, but, it’s posts like Grant’s that I appreciate because it helps broaden my knowledge base.

One thing that makes humans incredible is our ability of language and ultimately our ability to create forms of communication that transcend time.  None of us can learn EVERYTHING. But what we can learn is who knows more than we do, or how to access that information. If I want information on query tuning, I’m going to ask Grant or pick up one of his books. If I have a question on Power BI, I might reach out to Kellyn Pot’Vin-Gorman or Cathrine Wilhelmsen. In other words, I don’t need to be an expert on everything, though I’d like to be! I just need to know who to reach out to.

Similarly with my cave rescue world. I’m proud to say I work with some of the greatest people in the world, people who literally have written the book on cave rescue. And yet, at our recent meeting (the reason I was down South), two of my colleagues, Roger Mortimer and Eddy Cartaya reported back on their trip to Europe where they attended the ICARS conference and brought back some great information on how the Europeans are doing some things differently when it comes to cave rescue. This has prompted some discussion between Roger and myself on some medical topics.  Again, none of us are the complete expert on the field, but we know enough to know what we know and don’t know and how to learn more.

So, keep those tabs open and keep adding to them. I know I’ve got at least one video on air plane accidents I need to listen to when I get 30+ minutes. What tabs do you have open?

 

Use the steel carabiner!

“It’s stronger.”

As I’ve mentioned I’m an instructor with the National Cave Rescue Commission. During our classes we teach a variety of skills using a variety of equipment. Among the equipment we use are carabiners of various sizes and materials. The two most common materials are aluminum and steel.  Each has its advantages and disadvantages.

Aluminum is almost always lighter and this can be a real advantage when you have to carry a lot of them.

An aluminum carabiner may have a MBS (mean breaking strength) of 20kN (kiloNewtons or about 4,500lbs) along its long axis. (Different designs and different manufacturers will have different values, and orientation can make a huge difference).

A steel carabiner may have an MBS of 25kN along the same axis. So, it’s obviously stronger.

But here’s the thing. When we’re moving a patient, we have to look at the entire system.  In the NCRC we call this the system safety ratio (SSR).  You can’t look at just one component. Imagine using a carabiner (steel or aluminum) and trying to haul a patient with dental floss. It doesn’t matter what carabiner you use, that dental floss won’t get you very far.

And honestly, if you’re at the point where the strength of the carabiner is that critical such that the difference between 20kN and 25kN is critical, I would recommend you review your entire system.  There might be a better way of doing it. But yes, sometimes you MIGHT need that extra strength.

That said, why do students often reach for the steel carabiners in some cases? It’s not strength. It’s size and durability. Generally the largest carabiners we have are steel and they work best in the eyeholes of the Ferno litters we use. The Ferno has a load limit of approximately 2.6 kN. (Note how much less this is than the carabiners holding the litter! At this point 25kN vs. 20kN isn’t really important).

Besides fitting better, the steel carabiners tend to be more resistant to dings and scrapes and other forms of damage. In other words, it’s not as simple as “use the stronger one”.  It’s more complex and really comes down to “use the one that best fits the situation.”

I’ve mentioned previously the use of passwords and how we have rules we often follow in regards to them. I think it’s always worth understanding the WHY of rules and when to best apply them. For some accounts, I might have an easy to remember password because if it IS breached, the harm will be negligible.  For example, I’m a moderator for the sci.space.tech group on USENET (look it up if you’re below 40!). I have to log in about once a week to moderate an article. That account has a fairly simple password because in the worst case scenario, if someone DOES breach the account, the most they could do is… approve the 1 or 2 articles that come in each week. So it’s a password that’s “secure enough” (i.e. nothing anyone is going to guess from knowing me) but easy to remember.

On the other hand, the login for my E*Trade account is far more secure because if someone could access that, I could lose a lot of money.

So it’s not always “use the stronger one” it’s “use the one appropriate to the situation.”

This applies to many areas of life.

Janus 1 – 2018

As the year draws to a close, I thought I’d look back on the year a bit.

The goal of this blog has been to give me a place to reflect on the purpose of this blog.  I claim in My Goal Here to want to reflect on how we think and what drives certain decisions. And I suppose at times that’s true. At times it’s to give actual SQL or IT related advice.  But at times, it’s simply an exercise in my ability to put fingers to the keyboard and words on the screen and to be a bit self-indulgent if I’m honest.

My most popular page this  year was a mixture of things: The Streisand Effect. It was a bit of an activism piece about events at my alma mater and a chance to broaden my blog to more readers. But, it did also serve to actually reach one of my primary goals; to reflect on how we think and make decisions; primarily sometimes by trying to tamp down an issue, we only serve to draw more attention to it and to inflame things further.

My second most viewed piece this year was one of several on sexism, especially in the IT industry: Math is hard, Let’s Go Shopping. I still haven’t finished the book mentioned in the post, but it’s on my list to finish. The issue of sexism in my primary industry is one that has grown in importance to me and I expect to write more about it in the coming year and to try to do more about it.

Reviewing my SQL Saturday’s in 2018, I had the honor of speaking at Colorado Springs, or at least trying to, which I wrote about here; SQL Saturday Philadelphia, SQL Saturday Atlanta, SQL Saturday Manchester UK (my first overseas SQL Saturday, where I had a blast!), SQL Saturday Albany, and finally SQL Saturday DC. I also presented at the DC SQL User Group in September.  All great times and I had learned a lot and had a great time meeting new people and reconnecting with old friends.

I put in to speak at SQL Pass Summit, but again didn’t make it. But I still attended and had a great time.

I also was pleased to be asked to write for Redgate’s Simple Talk where I know have two articles published on using PowerShell for SQL: My first and second. I’ll be submitting my third article in coming weeks.

But not everything I did or wrote about was SQL related or even IT related. In late June, 13 people became trapped in the Tham Luang Nang Non cave in Thailand. This became a world-wide media event that a few weeks later I found myself part of. Besides at least four blog posts of my own that touched upon it, in my role as a regional coordinator of the National Cave Rescue Commission I did close to a half-dozen media engagements, including one for The Takeaway NPR program.

Oh, one more interview I did this past year was with Carlos Chacon and Steve Stedman of SQL Data Partners: it was a podcast I did with them. You can read about my thoughts here and listen to the podcast here. And definitely go to Amazon and buy my book!

Anyway, it’s been a great, and eventful year and I appreciate everyone who has read my blog and even more so to those who have commented on it, shared it, or somehow given me feedback.

I’m looking forward to 2019. I hope you are too.

Why the submarine wouldn’t work

I was going through my old drafts and found this post I had started to write earlier this year but never finished.  Actually it appears I meant this to be part of White (K)nights but I cut it out to make that post more readable.

During my media interactions I was asked multiple times to comment on Elon Musk and once or twice on his submarine. I tried to keep my comments fairly neutral, but the truth is, I and some of my fellow trained cave rescuers were pretty bothered by Musk’s attempted involvement. I got into at least one online debate about how the people in charge obviously were clueless and that Musk’s solution of a submarine was a brilliant idea.

It wasn’t and I figured I’d address some of my concerns.  Please note as with all situations like this, I was not directly involved, so I’m going on publicly available facts and my training as a cave rescue person and a cave rescue instructor. I am also not in any way speaking on behalf of the National Cave Rescue Commission or the NSS.

Now let’s discuss the device itself:

  • It almost certainly would not have fit. By all accounts, the tightest pinch was 15″ and hard to navigate. Anyone who has moved through a cave knows that even larger passages can be hard to navigate. Locally we have a cave that has a pinch that’s probably close to 15″, but that is at the bottom of a body sized V-shaped passage. Unless you can bend in the middle, you will not fit through it. A cylinder like Musk designed, would not fit. I don’t know the passages in the Thai cave, but odds are there is more than one passage where flexibility is important.
  • It also, in many ways was superbly dangerous. Once sealed into the tube, there would be no easy way to monitor the patient’s vitals. And if the tube had started to leak (cave environments can be extremely destructive, even to metal objects), there appears there would have been no recourse except to keep swimming and hoping to get to an air filled chamber quickly enough and that was large enough to debug the issue.
  • In addition, if the patients were not sedated, I’d have to imagine that being sealed into such a tube, even with lights for 20-40 minutes at a time would have been sheer terror. As it is, the kids were in fact apparently heavily sedated (a fact that some of us still find a bit surprising, even though very understandable), and yet at least one started to come out of sedation while in a water passage. Without being able to directly monitor the vitals of the patient, who knows what would have happened.
  • There’s probably other issues I could come up with. But let me end with this one. Rarely if ever do you want to beta-test or heck even alpha-test, which is what this would have been, a brand new design in a life or death situation when there are alternatives.

Like our White Knights, we want our brilliant tech solutions, but often we’re better off adapting what we’ve done in the past. In cave rescue we try to teach our students a “bag of tricks” that they can adapt to each particular rescue. Foe example, there is no single rigging solution that will work for every rescue.  How I might rig a drop in Fantastic in Ellison’s might be very different from how I’d rig a drop here in New York.  How I  package a patient for movement here may be different than in a Puerto Rican cave.  And honestly I’ve seen a lot of high-tech equipment get suggested for cave rescue that simply doesn’t work well in a cave environment and we often go back to the simple proven stuff.

I will add a tease, to perhaps a future blog post, of a mock rescue rescue where a high-tech approach failed after several hours of trying, and the low-tech solution solved the problem.

 

 

 

Safety Third

This is actually the name of an episode of Dirty Jobs. But it’s a title that has stuck with me because it’s near and dear to the sort of things I like to think about. Mike Rowe has a good follow-up article here. The title and show ruffled feathers, but he’s right, it’s an important concept to discuss.

You’ll often hear the mantra “Safety First”. This often means in work places things like wearing fall protection when working at height, or wearing a life vest when working in water, or ear protection, or other safety measures. The idea being that above all else, we have to be safe.

I got thinking about this while reading Rand Simberg’s book, Safe is Not an Option.  He argues that trying to make safety the highest priority of spaceflight is holding us back. I tend to agree.  And I’d like to argue out that despite NASA talking about safety in public announcements, the truth is NASA hasn’t always been upfront about it and also it has made decisions where safety wasn’t first (and I would argue in some cases those decisions were justified).

Now I know at least a few of my readers have read the Rogers Commission Report on the Challenger shuttle disaster.  It’s worth the read, especially Dr. Feynman’s appendix. One of the issues that came up during the investigation was exactly how safe the Shuttle was. (Here I’m referring to the entire system, the orbiter, SRBs and ET). Some at NASA were claiming that the Shuttle had a 1 in 100,000 chance at a loss of an orbiter. (a loss of a an ET or SRB as long as it didn’t impact the Shuttle wasn’t really a concern, as all ETs were lost at the end of each mission and at least 2 SRBs were lost due to other issues). As Feynman pointed out, this meant you could fly the Shuttle every day for 300 years and only have one accident.  What was the reasoning behind such an argument? Honestly, nothing more than wishful thinking.   As we know, the shuttle was far less safe, 1 in 67.5.  That’s a hugely different number.

There were many reasons that lead to either accident and I won’t delve into them here; though I would highly recommend The Challenger Launch Decision by Diane Vaughen as a comprehensive analysis of the decision making that helped lead up to the Challenger disaster.

But let’s talk a bit about how things could have been made safer, but NASA correctly decided NOT to go down that route.  One early iteration of the shuttle design had  additional SRBs mounted to the orbiter that would have been used to abort during an additional 30 seconds of the flight envelope1. I can’t determine if these 30 seconds would have overlapped with the critical 30 seconds Challenger’s final mission. But let’s assume they did. The total cost would have added $300 million to the development of the program and reduced the payload capacity of the orbiter2..

In a system already beset with cost considerations and payload considerations, this might have meant the program never got off the ground literally. Or if it did, it would fail to meet its payload guidelines.  All this for 30 more seconds of additional safety. Would that have been worth it? Arguably not.

Another design decision was to eliminate thrust termination for the SRBs. Again, this is something that would have arguably made the ascent portion of the flight safer: in theory.  The theory being that since you can’t normally shut down the SRBs, you can’t perform an orbiter separation, which means the orbiter can’t detach during the first 2 minutes of the flight and hence can’t perform a return to launch site abort.

But again, adding that safety feature didn’t necessarily make things better. For one thing, it really only would have been useful above a certain altitude since below that altitude all the orbiter could have done is detach from the stack and fallen into the sea with too little time to get into a glide position and make it back to a runway.

But there was a bigger issue: the thrust termination was determined to be violent enough it would probably have damaged the orbiter if used. This could have been mitigated by beefing up the orbiter structure. But this would have imposed an 8,000 lb payload penalty. Since the shuttle was already having trouble reaching its 65,000 lb payload goal, this was determined to be unacceptable3.

So, NASA could have made the decision of “safety first” and ended up with a shuttle system that never would have flown. And given the political calculus at the time, it’s unlikely NASA could have come up with a better solution nor had Congress fund it. The shuttle was an unfortunate compromise brought about a host of factors. But it did fly.

As I like to tie this back to some of my other interests; so what about caving and cave rescue.? I mentioned in a previous post how we’ve moved away from treating one line in the system strictly as a belay line. But what if I told you we often only use one line! There are many places in caving and cave rescue where we do not have a belay line. A good example is for a caver ascending or descending a rope.  This is called Single Rope Technique or SRT. There are some who come to caving from other activities and ask “where’s your belay? You have to have a belay!”

But, a belay line (here used in the sense of catching a caver from a potentially dangerous fall if their mainline fails) is actually far less safe.  I’ll give an example. First let’s start with some possible failure modes

  1. Main rope being cut or damaged to the point of failure
  2. The point the rope is rigged to (the anchor point) failing
  3. Your ascent or descent system failing

So the idea is, if one of those 3 things happen, the belay line will catch you.  But there’s issues with that theory. One major issue is that large drops in caves are often accompanied by air movement and waterfalls. The air movement, or even simple movements by the caver (and influenced by the rope in some cases) can cause a twisting motion. This means that before you know it, your belay line has been twisted around your mainline and you can no longer ascend or descend. You’re stuck. Now combine this with being in a waterfall and you’ve become a high-risk candidate for hypothermia, drowning, and harness hang syndrome.  In other words, your belay line has now increased your chances of dying. So much for the attitude safety first.

Even if you avoid those issues, you haven’t really solved the possible failure modes I listed. If you think about it, anything that’s going to damage your mainline is possible to your belay line. There are some differences, your belay line, for example because it’s moving is far less likely to wear through in a single spot like a mainline might from being bounced on during an ascent. On the other hand it’s more possible to suffer a shock load over a sharp edge if it’s not attended well.

If your mainline anchor point fails, you’re relying on your belay anchor point to be stronger. If it’s stronger, why not use it for your mainline? (there are reasons not to, but this is a question that should cross your mind.)

Finally, for equipment failure, catastrophic failure is rare (only seen in movies honestly) and other failures are better mitigated by proper inspection of your equipment and close attention to proper technique.

Of course the safest thing to do, if we were really putting safety first would to never go caving. But where’s the fun in that.

We can insist on safety first in much of what we do, but if we do, we inhibit ourselves from actually accomplishing the activity and in some cases can actually make things LESS safe by trying to add more safety. And safety is more than simply adding additional pieces to a system. It’s often proper procedures. Rather than adding a belay line, focusing on better rigging and climbing technique for example. Or even simply accepting that sometimes things can go sideways and people may be injured or die.  We live in a dangerous world and while we can make things safer and often should, we should be willing to balance our desire for safety with practicality and the desirability of the goal.

I’m going to end with two quotes from an engineer I respected greatly, Mary Shafer who formerly worked at NASA at what was Dryden Flight Research Center and is now the Armstrong Flight Research Center at Edwards Air Force Base.

Insisting on absolute safety is for people who don’t have the balls to live in the real world.

and

There’s no way to make life perfectly safe; you can’t get out of it alive.

For a more complete record of Mary’s thoughts, I direct you to this post.

Footnotes

    1. Space Shuttle – The First Hundred Missions. Dennis Jenkins, 2001. Page 192
    2. Ibid.
    3. Ibid

Train as you Fight

There’s a military aphorism “Train as you fight, fight as you train.” I was recently reminded of this by a friend mine and a reader of my blog.  We’ve shared a mutual interest in the space program for decades.  He mentioned this last week (though I can’t seem to find the post) in response to something I wrote and it got me thinking.

When we teach cave rescue, we almost always use a real patient in the litter. There’s a couple of reasons for this. For one, it ipso facto recreates the actual mass and weight distribution of a real patient. Now, there are training dummies that are similar in weight and mass, but they can be a pain in the neck. For one thing, ever try to move an inert body?  That’s what a training dummy can be like. Sure it’s great once it’s IN the litter, but getting it into position deep inside a cave can be almost impossible.

For another, it gives our students a chance to experience what being a patient feels like. This gives them a deeper appreciation for what it feels like to be moved through a cave. For example, you quickly realize that perhaps being dragged over the floor is less than ideal. Or, you learn as a patient what it feels like when your rescuers become nameless and faceless behind the glare of a dozen headlamps; next time you’re you’re a rescuer, you tend to keep in mind there’s an actual patient there and talk to them and treat them like an actual person, not a lump you’re moving through the cave.

And this leads to one of the biggest reasons: we don’t want our students to get in the habit of treating a patient like a lump in a litter. We want them to realize there’s an actual person in there.

I once did a practice rescue with a local sheriff’s department. Since it was their exercise, they set the rules. They elected to use a straw dummy as the patient.  They congratulated themselves on a successful rescue at the end of the exercise. I saw a disaster. For one thing, the litter was so light, they could have probably had one person pick it up and carry it out of the cave. This may sound like a minor or even funny nit to pick. But, it can lead the Incident Commander to misjudge the crew size that may be necessary in a real rescue. (We had a cave rescue here in New York State about 20 years ago where the patient was only 300 feet into the cave. It was so arduous that we ended up having to fly in cavers from West Virginia; all the local cavers who could fit were completely exhausted.)

Because of the lightness they were practically bouncing the litter off the ceiling and walls because straw dummies don’t scream in pain when they hit rock.  If they had tried to move an actual patient in that manner, they’d might have been surprised by the patient’s expressive vocabulary.

Training as one fights, or training as one rescues doesn’t necessarily mean that every scenario exactly recreates what you expect to happen. As another adage says, “no battle plan encounters the first contact with the enemy.”  So you might train with a mock patient who is 180lbs and has a broken leg.  And then in a real event, the patient is 240lbs, diabetic and has a broken pelvis, twisted ankle and dislocated elbow.  So no, you’re not going to practice every scenario. But you’re going to practice the general concepts and understand the ideas behind them.  You want an effective fighting force, you put them in the field. You have explosions, gunfire, smoke, rain, mud, etc. You don’t simply sit them in a classroom and discuss these points.

The flip side, fight as you train is important too. When the fighting or rescuing begin, you can draw upon your experience in training and will be far less panicked. I know at the few rescues I’ve been involved in, that once I’m on site, I’ve become very calm. The training clicks.  You can usually tell the untrained folks at an accident because they’re either panicking or have no idea what to do. The trained folks tend to react much more calmly. Also, trained people can act with a sense of urgency that doesn’t look like panic. Untrained people often move quickly, but without a sense of purpose. Don’t confuse moving quickly with moving urgently.

And all this applies to IT. I’ve said again and again that IT departments need to exercise their disaster recovery plans. It’s great to discuss them in a meeting and have a senior manager sign off on them. It’s another thing to actual practice mock disasters. This is when you realize that “oh Shelly is out on Wednesdays afternoons and only her computer has the phone numbers of the building manager.”  Or “Oh, we were sure that the batteries were in good shape, but turns out they’re getting old and we only had 1/2 the runtime we expected.” Or, as has happened too many times, “oh we thought we had good backups, until we went to restore them.”

And practicing your DR plans means you’ll be far less pressured when you execute them and as a result will make far fewer mistakes.

Today’s take-away: practice until it becomes second nature so that when you need to act for real it is second nature.

Failure is Required

Last week one of my readers, Derek Lyons correctly called me out on some details on my post about Lock outs. Derek and I go back a long ways with a mutual interest in the space program. His background is in nuclear submarines and some of the details of operations and procedures he’s shared with me over the years have been of interest.  The US nuclear submarine program is built around “procedures” and since the adoption of their SUBSAFE program, has only suffered one hull-loss and that was with the non-SUBSAFE-certified USS Scorpion.

The space program is also well known for its heavy reliance on procedures and attention to detail and safety. Out of the Apollo 13 incident, we have the famous quote, “Failure is not an option” attributed to Gene Kranz in the movie (but there’s no record of him saying it at the time.)

Anyway, his comments got me thinking about failures in general.

And I’d argue that with certain activities and at a certain level, this is true. When it comes to bringing a crew home from the Moon, or launching nuclear missiles, or performing critical surgeries, failure is not an option.

But sometimes, not only is it an option I’d say it’s almost a requirement. I was reminded of this at a small event I was asked to help be a panelist at last week.  It turned out there were 3 of us panelists and just 2 students from a local program to help folks learn to code: AlbanyCanCode. The concept of agile development was brought up and the fact that agile development basically relies on failing fast and early.  For software development, the concept of failing fast really only costs you time. And agile proponents will argue that in fact it saves you time and money since you find your failures much earlier meaning you spend less time going down the wrong path.

But I’m going to shift gears here to an area that’s even more near and dear to my heart: cave rescue.  At an overarching, one might say strategic level, failure is not an option. We teach in the NCRC that our goal is to get the patient(s) out in as good or better shape than we found them as quickly and safely as possible.  In other words, if we end up killing a patient, but get them out really quickly, that’s considered a failure; whereas if we take twice as long, but get them out alive, that’s considered a success.

But how do we do that?  Where does failure come into play?

One of the first lessons I was taught by one of my mentors was to avoid “the mother of all discussions.” This lesson hit home during an incident in my Level 1 training here in New York. We had a mock patient in a Sked. Up to this point it had been walking passage through a stream with about 1″ of water. But we had hit a choke point where the main part of the ceiling came down to about 12″ above the floor passage.  There was alternative route that would involve lifting the patient up several feet and then over some boulders and through some narrow and low (but not 12″ low passage) and then we’d be back to walking passage.  I and two others were near the head of the litter.  At this point we had placed the litter on the ground (out of the water).  We scouted ahead to see how far the low passage went and noticed it went about a body length.  A very short distance.

Meanwhile the rest of our party were back in the larger passage having the mother of all discussions. They were discussing whether we should could drag the litter along the floor, lift it up to go high, or perhaps even for this part, remove the patient from the litter and have them drag themselves a bit.  There may have been other ideas too.

My two partners and I looked at each other, looked at the low passage, looked at the patient, shrugged our shoulders and dragged the patient through the low passage to the other side.

About 10 seconds later someone from the group having the mother of all discussions exclaimed, “where’s the patient?”

“Over here, we got him through, now can we move on?”

They crawled through and we completed the exercise.

So, our decision was a success. But what if it had been a failure. What if we realized that the patient’s nose was really 13″ higher than the floor in the 12″ passage. Simple, we’d have pulled the patient back out. Then we could have shut down the mother of all discussions and said, “we have to go high, we know for a fact the low passage won’t work.”

Failure here WAS an option and by actually TRYING something, we were able to quickly succeed or fail and move on to the next option.

Now obviously one has to use judgement here. What if the water filled passage was 14″ deep. Then no, my partners and I certainly would NOT have tried to move the patient with just the three of us. But perhaps we might have convinced the group to try.

The point is, sometimes it can often be faster and easier to actually attempt a concept than it is to discuss it to death and consider every possibility.

Time and time again I’ve seen students in our classes fall into the mother of all discussions rather than actually attempt something. If they actually attempt something they can learn very quickly if it will work or not. If it works, great, the discussion can now end and they can move on to the next challenge. If it doesn’t work, great, they’ve narrowed down their options and can discuss more intelligently about the remaining options (and then perhaps quickly iterate through those too.)

So today’s take away, is don’t be afraid of failure. Embrace it. Enjoy it. Experience it. It will lead to learning.  Just make sure you understand the price of failure.  Failure may be an option and is sometimes mandatory, but in other cases, the old saw is true, failure is not an option, especially if failure means the loss of life.