I recently spent a little time in the beautiful state of Kentucky doing some rock climbing with friends. Sometimes, I wonder if there is a little overlap in the things I am passionate about. While I was there, I got to thinking about how similar rock climbing is to software development.
The first thing I realized is how both are inherently about problem solving. Software is developed because some problem exists, and the hope is that software will allow something to be done–or done more efficiently. Likewise, a climber must determine which moves to make in order to ascend a rock face. Poor problem solving may result in expending more energy than necessary, or failing to complete the route altogether (a route is just a predetermined path from the bottom to the top). In software, poor problem solving may result in lousy software, budget overruns, or total failure of the project.
That comparison led me to think about how risks are evaluated. A responsible climber will look at the wall and plan his route before even beginning to climb. And although every climber imagines being able to finish cleanly with no falls, safety devices (harness, rope, etc.) are used just in case. Similarly, software development has safety devices in the form of automated tests, which allow us to have more confidence that the product being delivered is the one that was expected.
Of course, a climber may not be able to anticipate every single move needed to complete a route. Some routes are just too long to remember every detail, and some details may not even be visible from the ground. But the climber knows his own ability and evaluates whether a route is doable. Failure to properly evaluate may result in abandoning the route and leaving expensive gear behind.
So it is with the development of software. We map out a project at a high level at the outset, with many of the details left to a future point when we’re closer to implementing them. But we don’t just make promises we can’t keep. We know our own ability and carefully evaluate what may be just beyond it (the sweet spot being a place that will enhance our ability without overreaching and burning out).
Both disciplines require mental focus. Fears (whether rational or irrational) may cloud one’s judgment. When climbing, this can result in falling or just wasting energy being overly cautious (again, safeties are there as backup, but ideally, one climbs as though they aren’t needed). In a software project, fears also have the potential to take the project in the wrong direction, or just slow it down through indecision.
This also stresses the importance of communication. The climber has a belayer who not only holds the other end of the rope, but watches his progress and warns about potentially dangerous conditions (e.g. improper placement of safety gear, bad foot placement if the the climber were to fall, etc.). Communication in a software team is even more diverse, as there is communication among the team itself as well as communication with customers. In all cases, fears may need to be alleviated in order to maintain a healthy pace.
Of course, this is not a perfect analogy (software requirements may change mid-project, while a rock wall shouldn’t change while climbing!), but it can be interesting to think about things from a different angle in order to gain new insights.