Book Survey: Chaos, Intuition, and Getting to the Party Early

I participate in book clubs for the same reason I read book reviews: I'm hoping to get my questions answered. Is a title worth it to purchase? That's what reviews and comments are for. Do you need to get the most out of a title, its symbolism, meaning, and potential alternative interpretations? That what makes a book club fun—at least to me.

When it comes to novels or fiction titles, I care more about the story and how the story makes me feel. Literary book clubs look to explore ideas and themes, often seeking a deeper meaning or to understand the context of the metaphors used in the story. Back at the workplace, knowing the "what" and the "how" and getting to the bottom of what I want to accomplish and put into practice, is the most important thing to me.

We can take the book club approach to technical books—reviewing several to explore something more deep, or broad, than we would find with a single book. We can look for complex answers to questions and issues where multiple authors disagree, to understand why and what that might mean.

For instance, consider the following questions: Where do "out-of-the-blue" failures come from? Why are we so bad at predicting them? Can making an infrastructure that focuses on finding problems earlier help us in the process?

These three questions could keep me up at night for weeks. Oh, who am I kidding? They have! It's also a problem that many authors have taken on from multiple directions.

Let's look at four of them.

Naseem Nicholas Taleb's The Black Swan: The Impact of the Highly Improbable suggests that "weird and random occurrences" are really not as weird or random, as we might think. They only appear that way because we haven't seen them. What's more, humans also have a tendency to be more sure about our so-called "orderly world" than we ought to be. So-called "Black Swan" events are not uncommon, but surprisingly normal. We see them through history all the time.

And that's a problem. With hindsight in mind, history looks predictable; we think to ourselves, "That should have been obvious." We saw what our fore-bearers went through and think we can avoid their mistakes. It's a nice narrative, but Taleb shows us that we are wrong more often than we would like to believe. (Consider the financial crisis of 2008 or your last show-stopper bug in production.) The real challenge is not dealing with history or a chaotic world, it is us, our biases, and the blinders we put on ourselves. How do we deal with all that uncertainty? Short answer: not very well. There are limitations to what our experience will teach us about future probability of events. The more dynamic and multi-faceted the issue, the less likely experience will prove to be an effective predictor of the future.

Why are we so bad at seeing these "Black Swans" in our lives and interactions? Daniel Kahneman's Thinking, Fast and Slow tell us we favor quick thinking over more deliberate and nuanced analysis. We sum up situations quickly. We look at certain cues, and those cues tell us "all we need to know," which is often accurate. That kind of sense-and-respond thinking is what Kahneman means by "thinking fast."

Thinking slow, on the other hand, comes up when you have too many things to float at the same time in your memory. A classic example is a detailed (but not too far of a stretch) multiplication problem, such as 372 x 513. Even the mathematically brilliant will have to stop and work through steps to figure that one out, even if it is done in their heads. Slow thinking costs a lot in the way of energy. We are hardwired to avoid it unless absolutely necessary. We frequently look to solve easy problems, not necessarily the right problems. We naturally balk when the situations get hard. We jump to conclusions.

We, as humans, use natural heuristics, and we try to recognize (and avoid) the biases that exist in our world. The problem is, even if we are alert, and focused on the biases we are aware of, there are dozens more that we have no idea we are falling into. I don't realize them until later, when I review my actions and say "Oh, wait, I see what I did there" (smack forehead). We are also inclined to believe things that more readily come to mind, regardless of whether or not that familiarity has any bearing on the right answer or even the correct problem.

We may think someone is extra talented, when in fact they may have been lucky when we observed them. More frequent observation of that person and others would likely give me a clearer picture, and help us avoid potential biases and pitfalls in our short-term thinking. That takes a lot of time and effort, so we often go with our first conclusion, based on emotion or intuition, rather than hard data. When there's no time to think slow, we will think fast. Fast thinking is appropriate and reliable for a certain kind of problem; it enables us to make sure to close the drawer automatically when we finish getting something out of a drawer, perhaps even for simple functional testing. But it leaves us liable to black swans. This leaves me asking, “How can I think fast (enough) yet well (enough)?”

If you think this might be leading into some thoughts about operations earlier into the development process, with continuous deployment, release, and interaction (what we casually refer to as "DevOps" today) you would be correct. The quickest and most direct introduction to this idea is Mike Loukides What is DevOps? Infrastructure as Code (which is free as a Kindle download and is only fourteen-pages long). Loukides gives a very quick tour of the ideas and the concepts behind DevOps, explaining why he feels the traditional operations model is problematic, and why it's "locked down" and hierarchical structure tends to be the cause (intended or not), of "compressed" development, test and deployment cycles. Loukides argues the point that the operations team isn't being replaced or outmoded, but instead that development, testing, and operation processes are able to be aligned more closely, work together much earlier than in traditional models, deploy more frequently, try out experiments, fail quickly, and roll back changes or fix the problems in somewhat real time.

What Is DevOps? won't answer all of the questions you may have, but it may whet your appetite for further exploration. If only there were some kind of case study that could be pointed to, or at the very least, some way to look at it without having to go through weeks of web searches and research (see, there's that thinking about fast versus slow again). I can't give you a "case study," per se, but after all this technical (and mostly psychological and statistical) reading, you might want to take a break and read something just for fun. That's what Gene Kim, Kevin Behr, and George Spafford offer with The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win . Yes, this is a novel, but you may well find yourself thinking over and over "oh, this so reminds me of my company!"

From the get go, it's a rags-to-riches (or "chaos to inner-peace") story of a company that looks to be doomed, seen through the eyes of its IT department. As a work of fiction, much of what is described is a bit capricious and daringly optimistic; the entire narrative takes place within two to three months. The real value here, at least to me, is that it puts us squarely into the middle of a struggling company and we see, in graphic detail, the missteps and painful choices made to deploy a make-or-break application. Over time, as the approaches used to date prove to be unsustainable, the various teams pull together and stop fire-fighting (as well as internally fighting), and look to remake the way IT and software development is done in that company. It's a neat, dramatic telling of how DevOps can grow organically in a company, and that it often happens in parallel to work already happening.

There is, of course, a sage Jedi Master in the form of Erik (who I chose to envision and hear in my head as the actor Sam Elliot) that helps our VP of IT learn about the path from the chaos of "fight to survive" to the orderly simplicity of early adoption, multiple experiments, and frequent deployment. Truth be told, on the literary front, The Phoenix Project is OK. On the ability to fire the imagination and thought processes of the everyday IT professional, and how they can envision implementing a DevOps environment in their own work, it is brilliant.

Conclusion
I like to read...a lot. I go through many books throughout the course of a year, usually one at a time. In isolation, many of the books I've read have given me good ideas, When I have a bigger challenge to consider, I’ll read several books. For the questions I originally posed, these four books, in my perspective, are providing insights greater than the sum of their parts.

The narrative that I have seen emerge is that chaos is common; habituated response fails for certain kinds of complex problems; experience doesn't count for as much as we think it does; and easy problems are rarely the right problems. Observe real examples of options, test them out quickly, learn from successes and failures, and use that information to help develop, test and deploy the next feature or fix.

If any of these areas sound familiar to you or if you are struggling with some of these issues in your organization, now might be a time to get your team together and sit down over a few books and see what you discover. My guess is it will be a lot more worthwhile (and dare I say it, fun) than taking a chapter a week in a single book and discussing it in a status meeting.

So there are four books. Have you read them? If you haven't, would you like to give them a try?

If you have, did I get the essence right, and what should I read (and maybe report on) next?