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! 

Skimmer's Guide - Don't Make Me Think (2nd Edition - Steve Krug)

WHAT STOOD OUT? 

Yes, it's a thin book (p. 6)

If something even LOOKS like it takes effort to use, it is less likely to be used. Steve has deliberately designed the book to be thin and thus appear to have "low opportunity cost". I find the meta beauty of this to be outstanding.

If something is hard to use, I just don't use it as much (p. 9) 

If a product is PAINFUL to use, I will actively seek to remove it from my life (glares at Windows and Internet Explorer).  

When you're creating a site, your job is to get rid of the question marks (p. 13) 

Don't make the user think! Bias your designs to making things obvious to the user. For instance, it should never be a question about whether something is clickable or not.

Conventions are useful, but boring to use! (p. 35) 

Web conventions are incredible useful, as they have well established patterns of usage. You don't have to train a user on how to use a navigation bar, it's standard now. On the other hand, conventions are terribly boring. It's hard to imagine your peers praising you for "great use of conventions".

The interesting piece of advice Steve offers out of this is: "Innovate when you know you have a better idea. Take advantage of conventions when you do not."

Omit needless words (p. 45)

A great quote from E. B. White, a rule in "The Elements of Style":

"Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts."

Get rid of "happy talk" on the site, anything that sounds like "blah blah blah". Same goes for instructions, make them unnecessary. Failing that, make them concise.

Some users search, some users browse (p. 56)

Steve likens searching a website with searching for an item in a store. Some shoppers will go direct to a person and ask for help, others will happily wonder around themselves. On websites, users may go direct to a search box or they may start browsing. It is important to cater for both styles.

Make sure that your search finds the right results and is effortless to use as well. Poor search capability leads to unsatisfied users, as per the story on page 69!

Show the navigation for all the potential levels before worrying about colours (p. 71)

Users usually end up spending as much time on lower-level pages as they do the top. This means that top-to-bottom navigation is important to work out from the beginning. To facilitate this, it's vital to have samples for each level of navigation. I liken this to seeing the forest through the trees, before you start arguing what colour the leaves should be :)

IF YOU READ NOTHING ELSE...

Don't make me think! (p. 11) 

Unsurprisingly the eponymous chapter of this book is a must read. Steve pleads with us that "if you have room in your head for only one usability rule, make this the one".

Someone who can barely work the Back button should look at your site and say "Oh, it's a ____".

This is further compounded by the later chapter where Steve implores us to make the choices on our website mindless.

We don't make optimal choices. We satisfice (p. 24)

A term coined by Herbert Simon, a portmanteau of satisfactory and sufficing. Steve points out that when we are faced with a problem, our normal behaviour is to pick the first reasonable solution for that problem. Users are unlikely to pour over your website to find the best option for what they want, they will most likely just pick "whatever looks good enough".

Keep the noise down to a dull roar (p. 38/39) 

A picture speaks volumes and the msnbc.com menu example is a great example of how simple black lines can ruin the user experience. When you're constantly fighting for the user's attention, you don't want a load of visual distractions to add unwanted noise.