Collaborating On Software: Optimising For Recovery

One of the mantras I like to follow when creating software systems is to "optimise for recovery" over "optimising against failures". This is embracing the fact that we're all human and thus mistakes will happen. In practice this means I focus on how quickly we can detect failures and repair them[0]Which is part of the reason I love TDD, the act of predicting and preventing failures BEFORE they even happen :D.

What I find novel is embracing this approach with how we work together. Accepting that we're not always perfect[1]Shocking, I know! and that we will make mistakes in how we communicate and collaborate.

Perhaps one of the most painful parts of this approach is dealing with the "production outage" level of mistake - a breakdown in trust.

Trust is tantamount in any relationship. In working relationships, I really like the definition of trust from Agile Conversations: 

1) I have expectations about what you will do that have been met before
2) I believe you will meet those expectations again, when we collaborate again in future

This is touched upon in Jeffrey and Squirrel’s podcast on Choosing Grief Over Guilt. It's unpleasant to experience behaviour contrary to my expectations, it is a violation of trust. It's not something to just skip over. The associated negative emotions won’t simply go away, or in the very least they won’t for me! Squirrel makes an excellent point: I can’t be curious[2]If I'm not in the mindset to be curious then my ability to effectively communicate is greatly inhibited.

If I was to try to power through this then it would probably lead to poor communication.

Poor communicate will probably lead to poor collaboration... and thus the spiral towards the Dark Side continues! until I deal with my emotions.

When trust is broken, guilt is not the answer. Guilt isn't helpful and neither is ignoring emotions. To recover from a breakdown in trust, it is more effective to first drain off the sadness, the anger and the frustration. I find this helps me get into a mindset where I can cultivate curiosity and thus more effectively communicate/collaborate.

So when working with others, I will take up the mantra of optimising for recovery. When mistakes are made, we can deal with the emotions first, so that we can move forward to rebuilding trust. I predict that, just as with software, it will make our relationships more robust in the long term.

Guilt Free Refactoring - Not Just The Codebase!

Last Tuesday we hit a really important milestone internally and we unveiled the fruits of our labour. It was a pleasure to see the culmination of work I've been doing with my amazing team since June 2020!

Reflecting on the week since Tuesday, I'm anxious with how little coding I've done. We've got so much work to do and I feel ashamed I'm not demonstrably making progress toward it.

I've found the best weapon against my shame[0]Thank you to David Genn who introduced me to my "shadow side" being a cause of my shame - neat little snippet on it is within this post. has been to council myself as I would council my friends or my family. I'm kind to them and firmly root things in reality. With this in mind, I ask, if you haven't been coding then what have you been doing? Here's the list:

• An emotional team retro involving a lot of shared vulnerability
• Discussing the migration to centralised authentication/authorization
• Catching up with one of our Product Directors on our shared vision
• Jointly designing the evolving cross-company microservice architecture
• Delving into the tradeoffs between Trunk Based Development & Feature Branching with one of the team leads
• Testing new remote pair programming tools[1]Tuple seems amazing. Cloud9 is great if you're on AWS and only want the "hit and run" cost.
• Organising sponsorship for the London Java Community Unconference
• Canvasing the web for new hires to join us on our epic quest
• Reviewing CVs and getting a feel for people brave enough to reach out to me!
• Diving into the intricacies of one of our legacy systems
• Facilitating a cross-functional retrospective tackling resolving conflict, decision making and communication
• Aligning product managers and technology teams on how we manage resource contention across products
• Digging back into one of our data sources, which I haven't touched since May
• As always, dealing with my anxiety!

Gee whizz, sounds kind of ridiculous to be ashamed when it is all written out in black and white like that. Perhaps that is what is needed though, to simply face the reality and accept it as it is[2]“When you argue with reality, you always lose – but only 100% of the time” - The Work by Byron Katie.[2a]Thank you kindly to livingunbound.net for helping me track down the quote/source!
.

I've done very little feature development and delivered very little into production this week. The important thing to note is I've made a tradeoff, that I've focussed my effort on what is effectively "refactoring the organisation". I never feel guilty when I'm refactoring code as part of TDD. So it feels odd to me to feel guilty when refactoring processes/communication/architecture across the organisation.

Naturally there is a balance to be struck here, it would be quite unlikely that I would be productive from simply refactoring all the time! I do want to take the stigma away from it though. Refactoring is something I want that to be proud of, whether it is codebase or a company!