Humans and Process
Agility and confidence in software development
I used to be very into freeride mountain biking. For those unfamiliar, it is an exhilarating sport whereby you don extensive protective equipment and hop on specialized burly mountain bikes to ride down ski hills with trails full of jumps and berms cut into them. Given the nature of the sport, it was prudent to check out your gear and your bike frequently, at least each day before boarding the lift.
One day about 8 years ago, I learned the hard way about relying on humans to check and verify things. I was about 10–12 feet in the air, having just launched off a drop feature I had ridden successfully at last 50 times prior. This time was different. Mid-air, my right foot slipped off the pedal and I landed hard on my hip. The resulting crash was painful, but luckily not too bad. I had a concussion but a few x-rays cleared me of a broken pelvis.
So what caused this? I checked over my bike before heading out that day. And I likely checked the previous few days as well. Each day, I noticed more and more pegs on my pedals had dropped out. The pegs are fairly important, as they dig into your shoes and help keep your feet on the pedals. So why didn’t I fix this? Or wait, did I actually check my bike that day? I can’t remember. See, I am human, and I was more interested in getting out and riding. I only get so many days on the hill and likely didn’t want to be slowed down. Plus, I rode that feature 50 times before without a problem. Surely 51 wouldn’t be any different, right?
What does this have to do with software engineering?
Confidence allows us to move quickly and release software frequently and reliably. High functioning organizations build confidence through practices including test driven development and full life cycle automation using pipelines. Testing applications and infrastructure, much like looking over a bike before a ride, helps identify potential problems so they can be fixed before you crash in production. Automated pipelines ensure necessary steps in the process are not skipped and are repeated the same way each and every time. And every time you successfully send a change through the pipeline, your confidence in it and your process grows.
In technology, everything will fail. Your organizational response to failure is often an indicator of how successful you are at reliably and frequently delivering high quality software. Too often, I see organizations respond to failure by introducing more humans as reviewers and gates into the process.
“From now on, Bob sign off on all changes. This will fix the problem.” — management
Not only is this slow but humans are, well, human. We often forget to do things, vary how we do things from iteration to iteration, and occasionally cut corners when under pressure. The effects of this approach are invariably negative.
On the flip side, high performing organizations identify issues, write and revise tests, and add additional automation thereby driving all manual functions from the release process. The net result is increased confidence as more checks occur and more manual (read: error prone) elements are offloaded to repeatable automation. Over time, this approach covers more potential failure cases and leads to a repeatable pipeline. The more often you identify an issue before production and the more frequently you successfully deploy to production, the more your confidence will grow.
So check your process and check your bike. Fix any problems and ride with confidence.
