A Violent Introduction to Self-Experimentation

August 18, 2013

rocket-sled-john-paul-stapp

It’s early on the morning of December 12, 1954 in the desert near Edwards Air force base. Colonel John Stapp is surrounded by men who are in the process of strapping him to a large metal chair. A warning klaxon sounds and the men retreat. Within a nearby bunker, a switch is thrown and electricity courses toward the man in the chair.

9 rockets fire simultaneously and 20,000 Kgs of thrust are delivered to the sled that the chair is attached to in just under 0.07 seconds. The sled, the chair, and the main lashed to it, leap down the 1000 meter track.

The initial acceleration was so severe that Stapp was slammed with a peak acceleration of 25 G’s – double the pressure that the Apollo Astronauts experienced riding atop a Saturn V

Over the nearly 20 second period of acceleration, Stapp’s face was distorted as the flesh tried to pull away from his skull. His eyes were forced back into his head, and the blood was drained from them, causing him to black out. Particles of sand that he hit as he accelerated to nearly 632 mph pierced his flight suit and his body, leaving burns and abrasions throughout.

He was blind, completely immobilized, and there was no way to steer the sled as he ripped down the track. It must have been like riding one of the four horses of the apocalypse. He set a land speed record that held for many years of mach 0.9. He was traveling at nearly the speed of sound on the barco-lounger from hell.

But that wasn’t the interesting part.

In this case, it was the abrupt stop at the end that was the whole reason for this explosive little journey. As the sled reached maximum velocity, scoops dropped out of the bottom and dug into a trough of water beneath the rails. The sled went from the speed of sound to a dead stop in under 1.5 seconds. The violence of this event for Stapp is still hard to comprehend.

The biomechanics of rapid deceleration were poorly understood at the time, but nevertheless gruesome. The deceleration forces exceeded 43 G’s. Stapp’s eyeballs deformed as they were forced forward and out of the eye socket and there was concern that they would be torn from his head if he didn’t keep his eyelids firmly closed. All the capillaries in his eyes ruptured. His brain sloshed forward within the confines of his skull, knocking him unconscious and leaving him with a severe concussion. He suffered an abdominal hernia and a series of minor bone fractures.

He was severely bruised and battered, but the amazing thing is that he survived the test. So what were they testing? Why in the world would anyone in their right mind subject themselves to this sort of injury?

Stapp was a pioneer in the exploration and discovery of restraint harnesses used by jet fighter pilots for use when ejecting from high speed jets in combat. Stapp was so dedicated to his mission to discover the safest harness for pilots that he used himself as the guinea pig.

He was famously quoted as saying that the only way of determining the point of injury is to go beyond that point. In other words, you don’t know how well it works until you break something – in this case: yourself.

It reminds me of the quote from Mario Andretti, “If you feel in control, then you aren’t going fast enough.”

Stapp’s pioneering work led not only to safety innovations for fighter pilots, but also to the introduction of seat belts in automobiles and passenger planes, in addition to child harnesses and restraints.

So what does this have to do with the way that we work in software? Pioneers like Stapp, whether they are in the air force or software development have always sought the limits of human capacity and endurance. They test the boundaries of human performance using the best subject that they have available – themselves. In fact, many wouldn’t dream of inflicting their wacky hypothesis on their friends, colleagues or grad students without first trying it out on themselves.

To me this reflects a few important things: People like Stapp are passionate almost beyond reason about discovering answers to the problems they are trying to solve. They experiment on them selves for a variety of reasons:

  1. They have courage: they would not ask someone else to take a risk they were not willing to take themselves.
  2. They crave immediate feedback: they are unwilling to accept second hand experience when they can experience the phenomenon themselves.
  3. They are leaders: they will go where no one else would dream of going

That’s nice, you say, but what difference does this make to my team?

First, all too often I see Agile coaches, self-proclaimed experts, and managers all too willing to proscribe how someone else should achieve high performance. My first question for them (and myself) is have you tried this? What direct experience or evidence do you have to support your assertion that we should all do things differently? Why would you experiment on your friends, but not on yourself?

Second, self-experimentation offers us the opportunity for the kind of rapid feedback and resulting learning that can dramatically improve our own effectiveness. Experimentation with groups takes time and persuasion. In the time it takes me to persuade a group to try out a single experiment, I can run dozens of experiments on myself. Why waste the groups time with untested ideas?

Thirdly, we are too satisfied with meaningless incremental progress. We are too comfortable going slow. We have forgotten what it really means to push our limits.

I am fascinated by self-experimentation. The more I look around me, the more I realize that there are endless opportunities for us all to explore the boundaries of human performance.

Whether it is accelerated learning, increased productivity, or enhanced skills, we have barely begun to scratch the surface of what we are capable of doing in software development.

“Most gulls don’t bother to learn more than the simple facts of flight-how to get from shore to food and back again. For most gulls, it is not flying that matters, but eating. For this gull, though, it was not eating that mattered, but flight. More than anything else, Jonathan Livingston Seagull loved to fly.

This kind of thinking, he found, is not the way to make one’s self popular with other birds. Even his parents were dismayed as Jonathan spent whole days alone, making hundreds of low level glides, experimenting.”

This is the experimental mindset we need to have in order to grow to our fullest potential. It is reckless, it is personal, and it is passionate almost beyond measure.

I have a confession to make: I crave the day that someone comes up to me, hands me a helmet and a mouth guard and says, “Strap in Tom, we’re going to do some pair programming”

So Bolt me to the chair

Light the rockets

Hang on tight and lets find out what we are really capable of!

Advertisements

Moving Too Fast

August 23, 2011

Sometimes I move too fast. Maybe my attention span has been eroded by all of that tweeting and the never ending Facebook updates. I caught myself skimming through a book the other day just so that I could catch “the good parts” or find something that caught my eye. I realized that the book looked pretty good and I would probably enjoy sitting down and reading it. But I put it aside atop my ever growing pile of books I don’t have enough time to read. I’m just too busy right now. I’m sure I’m not alone. Everybody has too many things demanding their attention these days. Children, house, work, friends…and the list goes on. We are cursed with over-rich and over-stimulating lives.

Obviously this has been on my mind of late as I rush about pell-mell from one meeting to the next. I’m starting to get this nagging
feeling that If I could just find a way to slow down a bit, I might be a much more effective person. Well, that begs the question, “What would slowing down look like?” Are there some constructive things I could do to more effectively manage the pace of change in my admittedly all-too-agile life? You see, sometimes I’d rather be really good at just a few things than mediocre at a lot of things.

So what can we do? Here are a few ideas:

  • Meditation: (Reflect) Take the time to reflect on what you are doing and how you are living
  • Journaling: (Make it Visible) Start to capture the frantic pace. This is the first step toward bringing it under control
  • Share it with others: (Transparency, Feedback) Share your experience with others and compare notes.
  • Apply time management practices: (Prioritize) Adopt David Allen’s GTD, Personal Kanban, or perhaps the 7 Habits. Whatever works best for you.
  • Measure: (Value) Use apps like Mercury App to rate your performance as you work to simplify and focus.
  • Stop blogging…Hey! Where did that come from?

Or maybe we should just go over to zenhabits. I’ll let you know how it goes…


Practice #1 – Speed Drills

December 17, 2010

In Daniel Coyle’s book The Talent Code, he talks about the different ways that people practice that ultimately enable them to achieve extraordinary results. One the things that he mentions is that a key component of deliberate practice is to speed up or slow down the exercise at hand. He gives some great examples of musicians who are asked to play their music so slowly that the tune would not be recognizable by someone listening to them. Alternatively they are asked to play the music as fast as possible, sort of like a 33 RPM record being played at 78 RPM. What does manipulating the speed do for us? Well, for one thing, it highlights mistakes. Mistakes that you might miss playing at regular tempo may be more readily detected when the pace is dramatically slowed down or sped up.

This strategy is also used by athletes. Dramatically slowing down an exercise is used to detect and fix weaknesses in form. Speeding up the exercise is also used to force mistakes that might normally not occur. The idea is to use varying speed to highlight flaws in performance, which in turn enhances learning. It’s pretty apparent how these strategies apply in music and sports, but how could we apply variations in speed to coaching software teams? A few ideas:

  1. Vary the length of the time boxes that you do development in. Yeah, you heard me right. Try dramatically shrinking the sprint length down to one week, one day, one hour. On the flip side, you could extend it – double it, triple it, quadruple the sprint duration. I know there are those who will try to convince you that this is a “bad thing”, but take it from me, you won’t go to hell for trying this. Shucks, try eliminating the sprints entirely (an infinite time box?).
  2. Vary the length of some of the meetings. If your planning meetings are usually an hour, try all day. If they are 4 hours long, try 10 minutes. Is your stand-up meeting always 15 minutes? How about making it thirty seconds!
  3. Speed up your retrospectives. What would happen if it was like a stream of consciousness game – each person has to blurt out the first thing that comes to mind to describe the sprint. If you don’t answer in 2 seconds then you move on to the next person.
  4. How slowly can you write code? As an exercise you might find that changing your development pace will have interesting effects. Try out the Pomodoro technique.

Will you make mistakes if you do these things? Hell yes! That’s the point! If you want to learn you need to make mistakes. That means you and your team have to be able to change the variables (in this case: time) in order to push your boundaries and learn new things. What I’m talking about is experimenting with the constraints that you apply to yourself and your team. You can’t experiment like that without breaking a few rules. Let’s face it, if you don’t find anything useful by experimenting with the speed of different activities, you can always return to the status quo and blame me.