Not too terrible. A bit "deliberate." By that, the tone of writing is very a-matter-of-fact, almost as if the writer was directing mental energy towards convincing the reader of the validity of his premises vs. writing in a expository manner detailing what this particular DevOps book is about. "Code was written. Tests implemented. Fatigue avoided." It got to be a bit irksome at times.
The "product-based" mentality appeals greatly to me, since it will avoid the "toss your shit-riddled codebase over the wall to the Ops team and call it a day" occurrence. Still, felt that this could have been more succinctly summarized. The books organization is OK, but hours and hours of reading made it hard to clearly delineate distinctness between the ideas in one chapter to another, to the point that every chapter felt needlessly redundant.
I could be a bad reader, since I want someone to "tell me what I should do." The suggestions and ideas are great, but may suffer from the harsh reality of people in mid-to-large organizations wondering how they should go about telling everyone they are doing it wrong and that our org structures are based on 18th century manufacturing practices (which they are). Describing this Next Gen Devops feels divorced from the tangible political context that employment in IT occupies. It may be that the person to read this should be execs who can implement these concepts by fiat.
Still, testing, ops, and dev interweaving their divergent skills sets into a product-based approach to systems and software == hotness. The historical differences elucidating the split between ops and dev probably was a bit longer than it needed to be, but valuable to internalize.
A decent book, but maybe not the best. Also, if I read the word "dependant" as I have read in this book one more time, I will probably stick a pencil in my eyeballs. A better editing job could have been done to avoid these sorts of things.