|
My climbing partner JP faces Looking Glass, ~500 feet of dimpled granite.
For all of those that don't know, I'm an avid rock climber and mountaineer. I've spent weeks at a time all over the east coast placing pro in offwidth cracks, rappelling down granite faces, and clipping the occasional bolt. I've also climbed Pico de Orizaba and La Malinche and several smaller summits.
My main climbing partner is JP, an enterprise software architect, a cock-sure, experienced Java developer with dozens of projects under his belt. I, on the other hand, am a slightly more cautious gameplay and animations engineer more recently out of college. So, as you can imagine, we chat about building software as we prepare our rack for the morning climbing and plot to take over the world (something he has already started, having recently launched his own startup) while passing camp hooch around the fire.
Over the past year and a half, I have worked on two amazing, triple-A first person shooters. I've had the pleasure of experiencing very different organizations with vastly diverse cultures. I've witnessed the grizzled, experienced veterans and the slightly newer, shinier, not-yet-proven team. Additionally, I finished a degree in computer science and, in doing so, led a team of nine software engineers for a year in the development of a video game engine for Creo Ludus Entertainment.
While hammering on some of Unreal's innards the other day, I had an epiphany about how I view projects. Now, I'll give fill disclosure, I'm a very, very process-oriented individual that has informally studied countless different sources. One of my good buddies is a SixSigma green belt and huge proponent of Lean; so, my view comes from an amalgam of these influences.
So, what is "the view"? Well, it's that a project is like an expedition.
The basic results of an expedition are pretty apparent:
- Your team safely makes it to the summit/top of cliff and safely makes it back to base camp.
- Your team nearly makes the summit and is forced to turn back for safety reasons and makes it back to base camp.
- Your team nearly makes the summit, is forced to turn around, and part of your team dies in a wild storm.
- Your team makes the summit, stays far too long, and a member gets acute mountain sickness, in the ensuing rescue attempt, half of your team dies, and the remainder make it down.
- Your team starts out, gets off track, and falls into a crevice never to be seen or heard from again... maybe in twenty years someone practicing high altitude rescue will discover your bodies.
I think you can see the point. Mountaineering is a risky venture, one that can't be taken lightly.
To have a successful expedition, you need:
Respect
When individuals on the team don't respect one another, teamwork and discipline break down. The instant that respect is lost, mistakes are made that will forever haunt your expedition.
JP and I were looking at the tall, long, run out expanses of Stone Mountain, a frightening slab of granite in North Carolina. Between pieces of protection, there are easily 20+ feet of run out. That means the potential for 40+ foot falls.
He looks at me with a smile on his face. "I think we should change the teams up." Up until that point, I had been climbing with JP. The two stronger, less experienced climbers had been together, with JP and me making slightly faster time due to our good dynamics, ease of communication, and familiarity.
I trust his leadership and respect him, so we have a quick discussion about it and do exactly that. I'm put as the second of one of the stronger climbers, even though I have more lead climbing experience. JP's plan makes sense to me. It's simple: I have rescue skills and the stronger climber doesn't. In a pinch, if she were to be knocked unconscious after a hard fall or hurt, I could rig something to perform an emergency rescue, she couldn't. It makes sense. It's a risk, one that I'm willing to take, but it makes sense.
Communication
Rock climbing has relatively standardized commands for running over routine elements (on belay, belays on, climbing, climb on, off rappel, off rope, off belay, on you, that's me, etc.). There's a common language spoken with understood words that are as simple as can be. Rope teams have their own sets of traditions and understandings that are expressed rapidly and uniquely.
No one is afraid to speak up. It's your life at risk, after all. If something wrong is happening, not voicing your opinion could lead to your death. I've been on an expedition where I didn't expressly say, "I think we should camp at 12,000 feet before moving to 14,000 feet" and, as a result, we didn't make it to the summit and one of my climbing partners got acute mountain sickness. I'll tell you that story (involving me helping my severely ill partner descend 3,000 feet down steep ice, getting off track, and nearly climbing out over the void) if you buy me a beer sometime.
Ownership
You are the team medic. That is your duty. You make my team no longer ill. You are god of "this man is too sick to climb." We respect you and follow your word.
You are the team's best climber. You have first dibs on summiting; but, you also are most responsible for the safety of the team (rescue attempts, etc.).
On the team, the strengths of each individual is known and respected. They own that domain. There is no question. On my Tennessee trip, JP was the most technically advanced climber, Matt was the strongest physically, Joanna was the second strongest, and I was the most first-aid knowledgeable and second most technical of the climbers.
JP picking out the tools he'll need to lead Looking Glass. There are a lot of options; but, having a firm grasp of his own ability and the purpose of each component, he can easily build a rack that will see him to the top.
But, what happens when...
Okay, so, that's a summary of how the "personal relationships" are. It doesn't speak about how decisions are made, situations handled, etc. All it does is set a framework in place that allows problems to be solved, instead of remaining there. In climbing, there's a culture of "speak up." It's your life. Speak up!
This, coupled with respect for your climbing partners and your ownership/mutual understanding of abilities, acts as a catalyst for problem aversion. But, what happens when a problem occurs?
First, you have to identify the problem. I have two examples:
Communication breakdown
JP and I were 250+ feet up on Looking Glass, climbing a traditional route that involved him placing gear as he ascended, building an anchor from bolts, and then belaying me up as I cleaned the pieces. Our rope was 60 meters in length (180 feet), and the climb was gently curving.
As I watch him, gusts begin to come in, hard and heavy. Quickly, my senses are overpowered as I pull myself into the thin layer of hardshell I brought, hood up to keep dust out of my eyes and the chilled bite of the wind at bay. I delicately put my face against the tight weave of my bluewater rope, feeling for the faintest hint of a pull. The tug comes and I let out more slack for JP as he leads.
Then, without warning, two hard pulls follow and I instinctively lock off. Either JP has just fallen a bit, or he's done something we hadn't discussed, but I rapidly figure out what he's doing. The wind was roaring at that point and my voice and his were easily drowned in the tumult. I take the device off the rope just as it's pulled quickly up, JP having secured himself to an anchor.
As it's my turn up, I progressively tug on the rope, a single, long pull, and any slack that remains is quickly taken in.
It's an old trick, one I hadn't known at the time. But, JP tried it, knowing that I've always been a quick study. It worked out. I successfully made it to his belay position without incident, smiles on both of our faces. Disaster averted due to quick thinking on both of our parts.
I knew JP would never put me in danger and I understood the process of climbing a route well enough to evaluate how the rope was acting at any given moment and what that meant about my climbing partner. This understanding led to us successfully completing that pitch of the route.
Loss at 400 feet
Mistakes happen. What's important is understanding that any misdirection can be solved, as long as it's visible and acted upon immediately.
At 400 feet, JP had climbed off route and created his own hook up to another route. In doing so, we were now climbing side-by-side with our other rope team. There was a problem that was almost immediately apparent.
The leader of that rope team had managed to drop her belay device. Without one, she didn't have the proper training (which JP and I both did) to create an impromptu belay device (see: Munter hitch). JP and I quickly discussed what to do.
I put him on belay and fed out slack as he got as close as he could. JP and I had a second rope with us for doing a double-rope rappel (a way to make our descent faster) and he quickly untied it and prepared for a rapid rescue. He tied a knot into the rope for weight and tossed it over.
The leader of the other rope team caught it, JP tied a butterfly to it and clipped his backup belay device. Quickly, she pulled it over and, after a few minutes of clean up, we were all in the green again.
JP sending a rope over to transfer a belay device at ~400+ feet on Looking Glass
Okay, okay, I see... But, what about...
A few more analogous elements:
- As a team, you never do your hardest mountain first. It's customary to climb easier routes to warm up or to summit smaller mountains first to ensure your team is running at optimal. It also provides you an understanding of how your team will operate and works out any potential issues ahead of time.
- Resting is just as important as climbing. Without rest, climbers burn out. This is true for on-route, between routes, between days, and between climbing trips (see picture below for a quick snack break at 400 feet).
- Don't fall moments. I've had JP call up to me while I was leading, "Hey, Andrew, you're at a ground fall." What's a ground fall? Exactly what it sounds like. Falling at that moment, regardless of what I do, would result in me splattering on the ground. It's important that this is flagged so that it's in the back of my mind. It lets me know "I need to place some protection, ASAP, or I'm risking everything."
Me! Resting on Looking Glass after having followed JP up a crazy link up pitch that combined two different routes. While waiting for our other team to catch up, we chowed down on some homemade energy bars.
Hitting the glacier on Pico de Orizaba. Taken at 17,000 feet, just as my climbing partner got ACM.
In summary, a successful project might not be the death-inspiring act of mountaineering, but it can benefit from the several hundred years of evolution climbing has gone through. While process and management are well documented, instilling the same fear that crafted these practices as an 18,000 foot volcano in Mexico is rather difficult. That being said, fear isn't required to learn from them.
As developers, it is our responsibility to learn from as many sources as we can, be it a hospital's implementation of Lean or a climbing team's successful process for assaulting K2. Within all great endevours there are lessons to be learned.
Let's all make our next summit attempt a success.
Me and JP on our successful summit attempt of La Malinche in Mexico.
About the author:
Andrew Grapsas is a software engineer in NYC. He interned at EALA on the current Medal of Honor and is now employed by THQ's Kaos Studios working on Homefront as a gameplay and animations programmer.
You can read his blog all about crafting stories and writing novels at www.aagrapsas.com. If you'd like to have him write more about process/development, e-mail him and let him know!
About the photographs:
Edit: Fixed typos and added two more links (SixSigma and Lean).
|
I mean: At university, we had to make a game every semester. And one big game during the entire last year.
I joined an old team, in the last "semester-style" project (the next one would be the big game, starting in the next semester). I figured that altough I was the newbie there, I was the most experienced in all areas (something unfortunate, considering that I am NOT an artist, or audio guy... yet I was more experienced in these areas too, but not talented). I pushed a new engine on them, and I failed to communicate clearly and properly in their communication style what I needed, we ended the project lacking several assets. And in the pitch (the projects end with we showing the working prototype and pitching it to 3 teachers with diffrent backgrounds, not disclosed to us who they will be), I and a shy guy would speak, someone went in desperation, and hurried the shy guy, this completly destroyed the pitch (he started to stutter, say non-sense, etc...). Yet, we barely did it.
Then the next year came, now a working game, to be made in 1 year. During the exact half of the project, the de facto team leader (he was the sole person with a producer personality on the team historically until I came up, the team was called "John Doe's team" even...), he left because of personal reasons. So, I was supposed to lead everyone, and proceed...
Then your article shows where I actually failed: They had no respect to me. I was a newcomer, with a completly diffrent culture (they for example loved soccer, I hated. Their most common way to socialize was watch a soccer game, or play Winning Eleven, while drinking some heavy stuff, and I am not much a drinker like that, and so on...), they considered me "bossy" (altough I was not actually bossy, they don't considered me their friends, and they only were willing to listen and hear friends...), and arrogant (mostly because I had to keep teaching stuff to them...).
This resulted into a really low morale, altough we managed to stay united, the work was slow, 1 week before the final deadline, we was 3 milestones late, and the project had actually, only 4 milestones, that mean that we only had did 25% of the game... In that emergency, I urged them to come to me house with their machines, we would build a impromptu garage-style studio, and crunch like nuts... Finally, it worked, altough it was a 2 week crunch (meaning that we missed the deadline by 1 week... of course, getting later penalized by that), we completed around 80% of the features, the game was done, playable, and somewhat fun (because we had no testing, my approach during the crunch of desining levels by randomly placing stuff, resulted into some pacing issues, mostly the game went from very easy, to very hard, to very easy again, several times, and randomly...).
We passed, barely, really, actually we was not supposed to pass, but at our pitch we surprised the teachers so much, completing the game in 2 weeks, that they allowed us to pass even without sufficient grades...
But, the team is over after that. I am with the game source code, each one moved to a diffrent place, and we don't plan to ever work again united, we figured that we failed as team. And I figured that I failed as producer, having a 2 week crunch, that made me get 10kg heavier in 2 weeks, and now needing to visit several medics, showed me, physically, how my lack of team-work led us to actual physical damage, to complete the project.
But this made me learn a lot, I am thankfull for the experience, and your article, it showed me a lot.
EDIT: Wow, I wrote a lot... I think that I can write a post-mortem for my blog :P
Man, I just read through the article, I have a mountain of typos :) Next time, I'll re-read first before submitting!