Why does climbing have a special relevance to the activity of software development?
What lessons can we learn from climbing and apply to software development? Can these lessons be applied to a broader range of activities.
Alistair Cockburn points out the parallels between software development and climbing, both are finite, goal-terminated cooperative games. Furthermore;
“Of all the comparison partners for software development that I have seen, rock climbing has emerged as the best.”
Agile Software Development – Alistair Cockburn
I also consider both to be games of high risk where the participants may loose more than they can afford.
Jim Highsmith’s Adaptive Software Development explores this analogy between climbing and software development still further.
Kent Beck once said that people who understand agile software development are agile in other things they do. Similarly maybe things learnt from one activity can be applied to another and vis-versa?
Both, when practiced properly are high discipline, low ceremony environments.
|Individuals and interactions over processes and tools||“More is less”|
|Working software over comprehensive documentation||Climbed routes over grand plans
“Talk – Action = 0″
|Customer collaboration over contract negotiation||“Come back alive and come back friends”|
|Responding to change over following a plan||Upward progress over following the guidebook|
So there are parallels between climbing and software development that allow practicioners of one to learn from the other. These lessons be extended to other fields of product development, for example Flexible Product Development. Conversely lessons from manufacturing can be applied to software development; Lean Manufacturing begat Lean Software Development.
The Power of Analogy
The power of analogy is particularly useful when it comes to software. It makes concrete an activity which is etherial and incredibly complex. By contrast climbing is very much grounded in the physical world. Climbers continually answer the question “How do I get there from here?”. This is a powerful question and can be applied not only to software development but also to many other problems.
The qualities of good climbing teams are also the qualities of good software development teams; trust, communication, cooperation and commitment. The skills required to build or participate in a successful climbing team are the same as those needed for software development.
Trust – other members of the team.
Communication – with other team members.
Cooperation – between team members.
Commitment – to the team, to achieving the objective.
Values for Life
If the things we learnt developing software in an agile way can be extended to other fields of product development and are also valued in manufacturing then maybe they can be of value more generally.