What do you think?
Rate this book
Effective Devops: Building a Culture of Collaboration, Affinity, and Tooling at Scale
This practical guide addresses technical, cultural, and managerial challenges of implementing and maintaining a DevOps culture by describing failures and successes. Authors Katherine Daniels and Jennifer Davis provide with actionable strategies you can use to engineer sustainable changes in your environment regardless of your level within your organization.
408 pages, Paperback
First published May 1, 2015
151 people are currently reading
928 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 40 reviews
December 3, 2016
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."
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."
October 29, 2015
Decent book. Think some folks were put off by many of the "soft skill" items mentioned at the beginning of the book instead of the presumptive battery of tools to "Do Devops" they may have expected. Common sense is not common, so I think many of the recommendations about inclusivity, diversity, and analyzing team makeup, to me seemed like "Duh" but felt that these sorts of discussions are needed because oftentimes people *dont* get it. The valley is the valley for a reason so I feel like the book has done a great job in broaching topics that those in managerial roles may not have brought to the front of their minds. I'm waiting for me.
Good book, and I'm hungry for more.
Good book, and I'm hungry for more.
September 24, 2016
Full disclosure: i'm a personal friend of the author.
This book is an excellent read for anyone who wants to learn more about devops and about how to improve computer operations in general.
One important thing this book really emphasizes is how important it is to create an inclusive workplace. As a white male, it`s easy for me to assume that there isn't discrimination in the tech world.
My one complaint is that this book concentrates a bit too heavily on Chef, however that is probably understandable given that one of the authors woks there.
I would really, really encourage all technical managers to read this book and think very carefully about what devops really means.
This book is an excellent read for anyone who wants to learn more about devops and about how to improve computer operations in general.
One important thing this book really emphasizes is how important it is to create an inclusive workplace. As a white male, it`s easy for me to assume that there isn't discrimination in the tech world.
My one complaint is that this book concentrates a bit too heavily on Chef, however that is probably understandable given that one of the authors woks there.
I would really, really encourage all technical managers to read this book and think very carefully about what devops really means.
June 12, 2017
Some of the observations were spot on and show me new way of understanding things that are going on at our company. The stories helped to explain presented ideas. I would maybe enjoy it even more if it was shorter :-D probably due to parts that i didn't find so interesting. Overall I'm happy that I came across it and would recommend it to everyone working in IT.
December 3, 2018
The book draws a clear line between what is tooling / processes and what is actually devops culture.
It makes you think about the usefulness and goals of processes and tools to build a devops culture rather than just throw a bunch of buzzle words about devops world. Sometimes it is easy get lost in this sea of new/crazy methodologies and forget why we do things and its essence.
It also addresses the affects and consequences that a blameful culture will cause and how avoid this kind of situation. Besides that, it also touches a delicate subject inside companies where "developers" have more prestige than others employees and how harmful it can be. In addition, the book also talks how a "rock star" culture might not be the right track and how it can be inefficient for the company as a whole.
It makes you think about the usefulness and goals of processes and tools to build a devops culture rather than just throw a bunch of buzzle words about devops world. Sometimes it is easy get lost in this sea of new/crazy methodologies and forget why we do things and its essence.
It also addresses the affects and consequences that a blameful culture will cause and how avoid this kind of situation. Besides that, it also touches a delicate subject inside companies where "developers" have more prestige than others employees and how harmful it can be. In addition, the book also talks how a "rock star" culture might not be the right track and how it can be inefficient for the company as a whole.
June 10, 2019
An excellent book on how to build a inclusive culture adapted to the pressure of devops work.
January 14, 2018
Focusing on the Culture of DevOps, Effective DevOps is a welcome addition to the literature on modern software development practice. It is a rare book in the field that begins with people and process, then moves to technology. The co-authors have anchored considerations of effectiveness in a broader social science perspective that I found very compelling. Recognizing that there is much new in the DevOps movement, they also place the movement in the broader context of software history. Everything you knew about highly functioning cultures is still true. In this light DevOps is more an evolution than a revolution, a perspective that I tend to agree with.
January 21, 2019
After first 100 pages I already want to throw it away. It mentions so often the word bias I started to have a bias for this word. Fortunately, it has also good advices. I will keep reading it, but for the moment just 2* for repeting to every few pages about the rasial/sexual problems of some people.
August 29, 2016
It took me a while to get through this book. Rather than laying out some good information on how to effectively build out a Devops organization, it seemed to be more like the annual workplace sensitivity training that one takes at most large organizations.
March 4, 2016
Good and broad primer for anyone wanting to start. Wide array of topics that are important for a successful implementation.
September 24, 2017
Seems like the books has a few points and ideas which are being covered over and over again.
September 16, 2017
The subtitle ("Building a culture of collaboration, affinity, and tooling at scale") is important here, because the book spends a lot more time there than on what I was expecting. Automation is briefly discussed,and even scaling is almost all about scaling hiring practices and team growth rather than technical scaling. It doesn't even spend much time on the portmanteau's "development" vs "operation," preferring to generalize to multiple teams collaborating. The book ends up wandering quite a bit through what the authors believe are best practices in collaboration and affinity (very little discussion of tooling even at a high level).
The case studies are the best part, as they are fairly focused and directly relate to companies' self-reported success in devops. Moreover, they include some different types of companies ("tech" companies to government to retailers).
One brief passage in the book, however, felt completely out of place, and knocked me into a far more critical read of the entire rest of the book. In a discussion about "group membership," the authors discuss "real names" in social networks (spoiler: they're against), in effect blaming the decision on insufficiently diverse teams. It's something the authors clearly have a deep opinion on; heck, it's something I have a deep opinion on . But it's a product decision that involves a variety of arguments which they didn't acknowledge: instead, it's a slam out of nowhere.
A lot of the book is spent on fostering diversity; I felt again in places that they stacked the deck (for example, on remote work,), and floating above issues where affinity groups conflict with inclusivity. There is a lot of advice here for managers looking to attract members of more traditionally underrepresented groups in tech (in particular women), but almost none of it seems devopsy (unless devops = "collaborative culture", which I think could be a fair takeaway from this book if not others).
I probably wouldn't recommend this book to most people, but it does have some meat within for people trying to improve cross-team collaboration and discerning sticky points inside a team.
The case studies are the best part, as they are fairly focused and directly relate to companies' self-reported success in devops. Moreover, they include some different types of companies ("tech" companies to government to retailers).
One brief passage in the book, however, felt completely out of place, and knocked me into a far more critical read of the entire rest of the book. In a discussion about "group membership," the authors discuss "real names" in social networks (spoiler: they're against), in effect blaming the decision on insufficiently diverse teams. It's something the authors clearly have a deep opinion on; heck, it's something I have a deep opinion on . But it's a product decision that involves a variety of arguments which they didn't acknowledge: instead, it's a slam out of nowhere.
A lot of the book is spent on fostering diversity; I felt again in places that they stacked the deck (for example, on remote work,), and floating above issues where affinity groups conflict with inclusivity. There is a lot of advice here for managers looking to attract members of more traditionally underrepresented groups in tech (in particular women), but almost none of it seems devopsy (unless devops = "collaborative culture", which I think could be a fair takeaway from this book if not others).
I probably wouldn't recommend this book to most people, but it does have some meat within for people trying to improve cross-team collaboration and discerning sticky points inside a team.
May 6, 2020
This book covers a relevant topic from IT industry and in a very detailed way. The "problem" I had while reading was the feeling of "running in circles" and reading the same topics all over. The need to highlight particular themes is valid, but I simply didn't like the repetition.
In general book is a great starting point for newcomers to the industry, engineers transitioning to the leadership/managerial roles, or similar. For someone who is long in this field it really looks like it doesn't have much to offer. But even for experienced people it does contain a number of useful references or reading recommendations. So it's worth checking the book.
In general book is a great starting point for newcomers to the industry, engineers transitioning to the leadership/managerial roles, or similar. For someone who is long in this field it really looks like it doesn't have much to offer. But even for experienced people it does contain a number of useful references or reading recommendations. So it's worth checking the book.
April 5, 2022
This is another book that i previously only have read specific chapters from, but now I managed to read the book from cover to cover.
Even though it is a few years old it still presents a good picture of what the term DevOps means in terms of culture and work environment and highlights common misinterpretations of what it is. The book does fortunately not contain much of any references to tools that quickly would have become obsolete. I will continue to go back to certain chapters in the future when needed. Highly recommended to anyone working in or with information technology and need to understand how to efficiently work together towards a common goal.
Even though it is a few years old it still presents a good picture of what the term DevOps means in terms of culture and work environment and highlights common misinterpretations of what it is. The book does fortunately not contain much of any references to tools that quickly would have become obsolete. I will continue to go back to certain chapters in the future when needed. Highly recommended to anyone working in or with information technology and need to understand how to efficiently work together towards a common goal.
May 10, 2017
A more correct title would be "Effective Operations and Organisational Culture", as the book, being well written, tries to touch upon all aspects of company's operations, people collaboration, and so on. Probably a good read for managers, but most likely they read 80% of it somewhere else already, and the other 20% is an overview of DevOps as a culture, and potential issues and perks that come with it. That 80/20 ratio between non-devops/devops topics is why the book feels bloated (at 410 pages!). But my view of the material doesn't correlate with what the author sees/understands as DevOps.
February 2, 2020
I admit skipping large parts of the book. It is in serious need of good editing: many repeated concepts, many chapters where the message could be communicated in a couple of phrases go on for 3 pages.
It's definitely not a technical book and the intended audience is managers. If you aren't one and are looking for technical or practical informations on DevOps, look elsewhere. And actually, just read something else as this is simply a too long of a book for the amount of useful info it provides.
It's definitely not a technical book and the intended audience is managers. If you aren't one and are looking for technical or practical informations on DevOps, look elsewhere. And actually, just read something else as this is simply a too long of a book for the amount of useful info it provides.
October 7, 2024
Ugh. What a mess. The same concepts are repeated ad nauseam. I wish I had a quarter for every time I had to read “there’s no one-size-fits-all approach” or some similar pedantic phrase. I’d then be rich enough to fund the research and construction of a Time Machine, which I would use solely to travel back to when this book was still being written. I would then beat the authors’ laptops to pieces with a claw hammer, thereby saving future readers from this heap of jargon.
January 10, 2025
some good points for someone who might be starting out in technology and wants to gain an understanding of how DevOps culture and mindset is different, but it just seems a bit vague. Some good case studies and the team building culture section seem just incredibly obvious.
I think this has some good points but in this day I don't think it's aged particularly well and could do with a refresh perhaps
I think this has some good points but in this day I don't think it's aged particularly well and could do with a refresh perhaps
April 14, 2018
A great introductory book on devops (note the capitalisation) and what it stands for as a culture. If you're looking for a technical book this is not it.
I believe labeling this a IT manager handbook would have been more apt. It delves deep into real cultural policies and it's impact on your organization
I believe labeling this a IT manager handbook would have been more apt. It delves deep into real cultural policies and it's impact on your organization
October 5, 2019
It is not technical at all, but there are good parts about the importance of the company culture and values for its success. Also fostering empathy, affinity, reasonable decision making in the opposite of "we have always done it that way" and how these things alongside people relations are equally important as technical things because software is created by people and for people.
January 13, 2025
There is a good book with solid advice somewhere along these pages, but it certainly is not about "DevOps" as I was expecting, to the point I am left wondering whether this book should have a different title.
I think this comment explains it brilliantly:
https://www.goodreads.com/review/show...
I think this comment explains it brilliantly:
https://www.goodreads.com/review/show...
June 2, 2017
Not really what I expected. I was looking for guidance on changing company culture and persuading leaders to embrace the efficiencies.
Pretty good, as far as It goes. Doesn't deliver the information I looked for.
Pretty good, as far as It goes. Doesn't deliver the information I looked for.
April 23, 2021
A bit different from what i expected, but cannot say that it is a bad thing. It changed my perspective on DevOps a bit and gave some new ideas. Now i know much more as well as what i need to dig deeper into.
October 14, 2021
The first 200 pages barely have anything to do with DevOps, but is actually rather sexist/racist. The book is very vague and slow at getting to the point. I would recommend The DevOps Handbook any day over this one.
December 2, 2021
Great book to learn how to build a good devops culture. The book explains a lot of tech terms so it's really friendly and easy to understand it.
October 22, 2022
I wish i could rate it lower, verbosity at its elegant best, 5% of the content is relevant to audience if at all.
September 7, 2024
Reading the book itself is quite ineffective….
March 18, 2017
Great book! I will be recommending it to several people in our organization.
I picked up this book assuming that it would a technical book, perhaps more focused on tools and automation of build and deployment processes. I was wrong and pleasantly surprised.
This book is full of great insights into how teams and individuals work and the culture of collaboration. It’s a “compulsory reading” if you are serious about devops and changing the way organizations work.
Don't say you are doing devops until you read this book and truly understood what devops is about. Many people in IT industry get it wrong and their use "devops" as a term is overloaded with misleading meaning. Devops is about working together, collaboration.
I picked up this book assuming that it would a technical book, perhaps more focused on tools and automation of build and deployment processes. I was wrong and pleasantly surprised.
This book is full of great insights into how teams and individuals work and the culture of collaboration. It’s a “compulsory reading” if you are serious about devops and changing the way organizations work.
Don't say you are doing devops until you read this book and truly understood what devops is about. Many people in IT industry get it wrong and their use "devops" as a term is overloaded with misleading meaning. Devops is about working together, collaboration.
February 25, 2017
I did not start out liking this book. I spent half the book thinking about what "DevOps" was, hoping that a definition of some sort would show itself. It didn't.
But over the course of reading it, I sort of gathered what DevOps was about, and the mental representation of "DevOps" that I developed suddenly made everything else make sense.
Being the manager of an analytics team, which deals a lot with people and technology, I found this book insightful, useful, and applicable. The team management ("blameless culture") and stakeholder management bits especially were great.
But over the course of reading it, I sort of gathered what DevOps was about, and the mental representation of "DevOps" that I developed suddenly made everything else make sense.
Being the manager of an analytics team, which deals a lot with people and technology, I found this book insightful, useful, and applicable. The team management ("blameless culture") and stakeholder management bits especially were great.
August 5, 2016
The first thing to note is that the full title of this book is "Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale ". It covers many aspects of dev ops; not just the tooling ones that us developers like to read about it. This is good because all the aspects are important. The book really lays upon you the idea that DevOps is about culture. If you don't come away from the book thinking about the non tooling aspects of DevOps, I'd be surprised.
There are 6 parts to the book. I really liked parts I, IV, V and VI. Parts II and III felt like a bit of a slog.
The first part is six short chapters giving an overview of concepts and terms. This was very fast moving and had some good quotes and concepts. It was a lot lighter to read than your typical O'Reilly book while still teaching you what you'd want to know. The "history of dev ops" going back to the first computer felt like a bit much, but it is an intro. I was surprised to see the word "portmanteau" in the book multiple times. I just learned that word last year so I think it could have used a definition. Chapter six is the four pillars of dev ops and came in at 2.5 pages. I liked this as it highlighted something simple to remember as a really important concept.
The next four parts are about the pillars. The first two pillars are collaboration and affinity. It took me most of the week to get through this material. It's management/soft skills type stuff. Unfortunately for me, this is when the typical O'Reilly style showed up. A lot was covered quickly and succinctly. And a lot wasn't new. These sections could have used more examples. I thought there'd be more examples from Etsy since they have such strong practices. Preferably sprinkled through the chapter to aid in alertness. The last chapter of each part covers anti-patterns. The style of these chapters was easier to read and they were shorter. The other two pillars are tools and scaling. Those were easier for me to read. I also felt like there were more case studies sprinkled in for scaling which was helpful. The variety of companies covered in the case studies was also helpful. I also liked the emphasis in the last part for stories and how to use them well.
I did come away with new ways of looking at concepts which is important in this type of books. I like the “new words” like islands instead of silos and thinking about folk models.
I give this book 8 out of 10 horseshoes.
Disclosure: I received a review copy of this book from the publisher for reviewing it on behalf of CodeRanch.
There are 6 parts to the book. I really liked parts I, IV, V and VI. Parts II and III felt like a bit of a slog.
The first part is six short chapters giving an overview of concepts and terms. This was very fast moving and had some good quotes and concepts. It was a lot lighter to read than your typical O'Reilly book while still teaching you what you'd want to know. The "history of dev ops" going back to the first computer felt like a bit much, but it is an intro. I was surprised to see the word "portmanteau" in the book multiple times. I just learned that word last year so I think it could have used a definition. Chapter six is the four pillars of dev ops and came in at 2.5 pages. I liked this as it highlighted something simple to remember as a really important concept.
The next four parts are about the pillars. The first two pillars are collaboration and affinity. It took me most of the week to get through this material. It's management/soft skills type stuff. Unfortunately for me, this is when the typical O'Reilly style showed up. A lot was covered quickly and succinctly. And a lot wasn't new. These sections could have used more examples. I thought there'd be more examples from Etsy since they have such strong practices. Preferably sprinkled through the chapter to aid in alertness. The last chapter of each part covers anti-patterns. The style of these chapters was easier to read and they were shorter. The other two pillars are tools and scaling. Those were easier for me to read. I also felt like there were more case studies sprinkled in for scaling which was helpful. The variety of companies covered in the case studies was also helpful. I also liked the emphasis in the last part for stories and how to use them well.
I did come away with new ways of looking at concepts which is important in this type of books. I like the “new words” like islands instead of silos and thinking about folk models.
I give this book 8 out of 10 horseshoes.
Disclosure: I received a review copy of this book from the publisher for reviewing it on behalf of CodeRanch.
Displaying 1 - 30 of 40 reviews