The Mountain Mind - Mountain climbing and software development are the same
When planning a climbing trip the goal of reaching the summit is often known, but how tough it really is to get up there is something that can only be judged in detail once the climbing starts. Some mountains look almost impossible to climb and yet they are relatively easy to summit, while others look comparatively tame but require quite some effort to get up to. Starting a software project is often very similar. While there might be a general idea of what problem or business case the software should solve, it is often unclear what is needed to get there. Some things might turn out much harder than anticipated, while others will be solved surprisingly quick.
Developing a software product often has many unknown factors contributing to whether the development will succeed or fail, not all of them of technical nature. The team might not know each other well enough or they might not be familiar with some of the technology involved. When climbing a mountain the first time it might not be known where the most difficult parts of the wall are, how the weather will develop, and maybe the rope party does not know each other well enough to know how each person reacts under stress. Nevertheless, if one wants to summit a mountain, one has to start climbing and if one wants to ship software one has to start coding at some point.
Committing to success
No matter how the preconditions were, once the climbing or the software development started, a certain commitment from those involved is needed, or else the team plods along listlessly and gets nowhere. People need to be engaged and be able to focus without distraction on the project ahead, especially when facing a challenging situation. For best performances, ideally, people reach a flow-state when climbing or coding. Being in the flow is often defined as being fully immersed, feeling energized, and having a positive focus on the activity being performed. This implies being committed to the undertaking and committed people are willing to invest time, nerves, and energy to reach the common goal.
For software development, this often means committing to a product and a team even if it sometimes might be difficult to go forward. Sometimes a bit of grit, resolve, and stamina is needed to overcome a nasty situation - whether this is a turn for nasty weather or a particularly elusive regression bug. Generally, the further one progresses, either in climbing or in software development, the bigger the negative consequences of abandoning the project are. When developing software this often comes down to having wasted quite large amounts of money, when climbing this could mean that one has to be rescued out of a wall or worse.
Every ambitious undertaking will get tough sometimes, and there will be moments when the frustration gets high. But if people are committed they accept this willingly.
Being committed and accepting that there will be moments where it is going to be tough is an important factor to success at challenging projects. On the other hand, being committed means taking over responsibility for one’s actions and decisions. If the lead climber chooses a more interesting route than planned this means everybody else has to follow that way, even if the difficulty might be increased. When software engineers make technical decisions regarding a project, this affects the people tasked with maintaining or further developing the product in the future.
Where things go wrong
It’s not just the developers that need to be committed. The customer or sponsor of a project also has to invest their commitment, if one wants to succeed. If a customer fully backs up a project and is willing to invest time and expertise the risk of failing to ship the software successfully dramatically decreases. If a customer has a hard time expressing their wishes regarding a product or if they are unwilling to invest time on their side into a project, this might be a hint for a lack of commitment.
Another large factor to influence the level of commitment is the risks involved in doing something new. Some risks can be reduced and controlled to some extent, but some risks are inherent when doing something. In the mountains the weather might change suddenly, a rock can break loose or material fatigue might cause an anchor to fail. Or a global pandemic might disrupt the economy, a critical security bug might be happening in a widely used library. These risks, often very unlikely to happen, are not reducible.
However, many risks can be mitigated very well. Over the years I identified three major factors that contribute to increased risk and accidents when climbing or developing software: Ignorance, casualness and distraction.
Ignorance means that we just do not know enough or that our skills are not developed far enough. Reducing ignorance is done by learning and gathering experience which is done relatively easily by regular training and education. In this context casualness means, that we underestimate the seriousness of the situation or overestimate our abilities to solve a problem. Reducing casualness is done by increasing the system awareness and getting a grasp of the surrounding context. Something that comes with experience in the field and being exposed to similar situations frequently. Retrospectives and reflecting together are also good methods to turn the implicit experience into active knowledge. Distraction means that we cannot focus on the task at hand for whatever reason. This is where commitment and focus come into play.
The circle of risk and commitment
The combination of focus and commitment reduces the risks. If we work on a product that is only a triviality and a side-project of a customer the risk of failure or not reaching the goal is often increased. Typical symptoms are the inability to define clear goals, roadmaps, or the unavailability of persons responsible or able to decide something.
When climbing having a distracted or uncommitted member in the party might put the whole rope team into danger. Unfortunately, being scared is highly distracting for most people. This creates a vicious cycle where people are scared and do not trust each other which in turn makes them lose focus which again lessens trust and heightens the feeling of immediate danger. If unchecked, this cycle continues until either an accident happens or the project is abandoned. Added to this is the fact that people not being committed to a project often tend to estimate risks higher.
There are various influencing factors that we can control to escape that vicious cycle. Reflecting with the team about the risk in general and the risk perception of each individual member is a great start - no matter if climbing or hacking. Learning to keep the focus despite being scared is a great asset. Exposing yourself to the risks in a controlled environment can be a very effective way for learning this. When climbing this could mean going to the climbing gym and falling in the rope on purpose. When writing software hackathons, coding dojos and doing small low-stake projects are other ways.
Another huge leverage to break the cycle is to give people the time and context to be able to focus on the project on hand. This means not overloading them with many different tasks and projects and creating stable teams where people feel safe and where it is easy to get help. Teams that know how each individual perceives risks and how people react to perceived danger and pressure often perform extremely well. These teams often find it easier to commit themselves to a project early on, despite many unknowns, because they know how to overcome tough situations and are often adept at learning and reflecting. And this in turn helps to reduce ignorance and casualness, the other two factors for accidents - No matter if climbing a mountain or delivering awesome software products to users.
–
(This article was originally published at bbv.ch in german
