Review: Effective DevOps by Jennifer Davis and Ryn Daniels

This book has two problems: first, they don’t define DevOps; second, they don’t define the target audience. As a result, while the book contains a lot of interesting content, it’s arranged in a way that makes it very difficult to learn.

Now, you might argue, “but wait, they do define DevOps, right in Part 1!” OK, let’s look at their official definition:

“DevOps is a cultural movement that changes how individuals think about their work, values the diversity of work done, supports intentional processes that accelerate the rate by which businesses realize value, and measures the effect of social and technical change. It is a way of thinking and a way of working that enables individuals and organizations to develop and maintain sustainable work practices. It is a cultural framework for sharing stories and developing empathy, enabling people and teams to practice their crafts in effective and lasting ways.”

OK, close your eyes, and tell me, what did that paragraph say?

It’s hard to repeat, isn’t it? That’s because their DevOps definition is vague and deliberately avoids any concrete details. If I remove the word “DevOps” from that paragraph above, it could be about anything. The rest of that first part makes you feel like you’re trying to hold on to a slippery fish: they spend a ton of time defining what DevOps is not, repeating dozens of times “there is no one true DevOps”, and actively dodging and denying any concrete details to the point where, no matter how much you try, you can’t grasp it. They even acknowledge this fact in the book itself:

“There has been some discussion in the devops community as to whether or not devops has lost its direction. Critics of the movement say that it is too defined by negative spaces, by people saying what devops isn’t rather than what it is (or not providing a concise definition for it at all). “

Yup, I am one of those critics. It seems like the authors attempted to be as all-inclusive as they could be, but the result is that this isn’t a book about “Effective DevOps,” but rather, a haphazard collection of things the authors believe lead to “Effective Companies.” And while one of the goals of DevOps is to make a company more effective, you can’t really claim that everything that makes companies effective should be put under the umbrella “DevOps”. Their definition is too broad, and as a result, the message of this book is very diluted.

It’s also diluted in the sense that the book tries to speak to a bunch of different audiences. Some parts are targeted at developers; some at operations people; some for managers; some for HR; some for the CEO; some for the legal team. Depending on who you are, you’ll find a few parts interesting, and the rest will feel largely irrelevant.

I’ll also mention that while the book talks a lot about avoiding unconscious biases, it falls to some itself.

For example, one is the odd stereotype that a “10x engineer” is always a “10x asshole” that no one wants to work with. The real 10x engineers are 10x precisely because others love working with them and are more productive as a result.

Another one is the assumption that the differences between tools (e.g. programming languages, cfg mgmt systems, etc) don’t matter. All that matters is how you use the tools. It’s certainly true that with the wrong workplace culture, even the best tools will be ineffective. But the opposite is not true: even the best culture won’t succeed with the wrong tools. There is a reason Etsy isn’t written in assembly; there is a reason you use a config mgmt tool like Chef or Puppet and not manual shell scripts; there is a reason you store data in an RDBMS like MySQL and not flat text files. There is a right tool for the job and it’s worth the time to find it.

All of this is a shame, as there is some excellent content lurking in these pages. There are great discussions of diversity and minorities in tech organizations. The authors could extract those discussions, go into more detail, and turn them into an great standalone book focused on that one topic. The case studies scattered throughout this book are intriguing too, as they contain real-world stories, with concrete details (!) of how DevOps actually works. Again, the authors could extract those stories, go into more detail, and create yet another interesting, standalone book on “DevOps stories.” Chapter 18 has lots of interesting stories about promotions, transparency, evaluating organizations, and cultural debt (what an awesome concept!). Again, a standalone book on Cultural Debt would’ve been a great read!

But as it is, all of this intriguing content is crammed into a single book, organized poorly, and only explored at a surface level.

As always, I jot down interesting quotes as I read. Here are some of the best ones from this book:

“There is a sea change happening in software development and operations, and it is not simply the introduction of a new word into our lexicon—it’s much more than that. It is a fundamental shift of perspective in the design, construction, and operation of software in a world where almost every successful organization recognizes that software is not something you simply build and launch—it is something you operate.”

“If someone isn’t on the right track with something that they’re doing, waiting up to a year for their next annual review isn’t good for anyone involved. They will likely go through this time thinking they are doing well, leading to a nasty surprise come review time. The psychology of getting feedback shows that people generally react to these sorts of negative surprises emotionally rather than intellectually, a phenomenon known as amygdala hijacking. As a result, people are less likely to fully understand and be able to act on the feedback they are being given.”

“One of the differentiating factors between a group and a team is the presence of trust.”

“James Stewart, director of technical architecture at GDS, recounted the general approach for tool selection, shown in Figure 14-4, via a quote from JP Rangaswami:

For common problems use Opensource.
For rare problems use Buy.
For unique problems use Build.”

“Disallowing remote work reflects a culture that values the appearance of doing work more than the effectiveness of the actual work.”

Rating: 2 stars