Let’s compare a sports situation with software dev best practice. There was recently a huge failure in the refereeing of a football match. A decision was made that processes should have corrected. Gary Neville here is saying refereeing is difficult & sorry should be enough here. https://t.co/NN6tvZzW0X
— Harry Bailey (@HarryBailey) October 3, 2023
In software development we do ‘inspect and adapt’. That is we look at our processes and find ways to improve. We’re transparent about failure and actively look for places we can evolve.
— Harry Bailey (@HarryBailey) October 3, 2023
A ‘sorry but’ wouldn’t be acceptable. “Oh there is a demand for speed so we’ll fail occasionally” and “that’s just the way it is”
— Harry Bailey (@HarryBailey) October 3, 2023
The least we’d offer is…
— Harry Bailey (@HarryBailey) October 3, 2023
Sorry
Here is why it failed
Here is what we’ve done to improve the situation
When you don’t offer those things, people (clients or stakeholders) will go looking for the improvement / failure themselves
— Harry Bailey (@HarryBailey) October 3, 2023
And that is exactly what has happened with the football VAR failure. Where no change is promised, a change is demanded. It’s a valid ask, and a basic expectation of the consumer of any service. Here that’s refereeing.
— Harry Bailey (@HarryBailey) October 3, 2023