A lesson from the river

When the week is over, I love nothing more than to head out of town into the clean air and freedom of the wilderness. Being a bit of an adrenalin junkie, I often choose some rather adventurous way of doing this. In particular, I love to kayak the sort of rivers that send shivers down the spine of normal people. While I kayak purely for enjoyment, I have found that the experiences from the river often alter how I think back in the office.


You see, software development is a little like kayaking in that both are team games. On a river you depend on your mates watching out for you in order to paddle something too dangerous to paddle alone. This is not much different than a software project which requires you to work with
other developers to create something too big to finish alone.

The big difference between the two situations is the level of risk you play with. With kayaking you don’t just play with your job and lifestyle, you literally play with your life. For those who can accept the danger it is a a perfect way to gain risk assessment muscles.

Kayaking has taught me that I should not study just the rapid I want to paddle, but I must also look downstream. What will happen if I take a swim? Is there a nice pool after the tricky bit or does the river flow into a deadly rock sieve? In many cases a grade V river with pools is easier and less dangerous than a continuous grade IV river with no place to rescue a swimmer.

On a river I refer to this concept of the consequences if it all goes wrong, by the unforgettable term, “F*** up factor” (FUF). In the office you may prefer to use “Consequence”, but the concept remains the same. Risk management is more than just asking “What is the likelihood of it all going to plan?” It’s also about asking “Can I live with the consequence if this doesn’t work out as planned?”

While we all think this way to some degree, I often see people behaving in ways that makes me think their FUF muscles aren’t strong. Perhaps a person will balk at trying a new idea (high risk, but low FUF as all you are losing is development time), yet would change the database on the production server without a dry run if the rest of the team didn't prevent it (medium risk, high FUF because it could affect all our customers).

Or consider the FUF of an exception in test code vs production code. While it’s equally important both code bases are maintainable, the FUF of an exception in our test code is nearly zero. Therefore when writing test code putting in exception handling code probably isn’t worth the effort. But for production code we probably want to think of the FUF of every exception and handle it appropriately.

A further benefit of FUF analysis is that it may help you feel more confident when dealing with the unknown. After all, if you have accepted that you can live with the FUF should it all go to custard, then your brain can stop worrying about the possibility of it going wrong. That should allow you to focus on the more important task of making it go right.

I recommend you give FUF analysis a try. It should make you develop a more appropiate application for your users and hopefully make you more adventurous in the process.