Top positive review
A fantastic book about DevOps. Ironically, it has the same flaw DevOps does...
Reviewed in the United States on December 1, 2017
DevOps is this mythical assembly line of progress that gets code from point A to point B in record time, and by record time, I mean no time. Coded, auto-tested, out the door, bing, bang, boom. The book was an entertaining read (and/or listen) and the authors cleverly couch the concepts of DevOps into a story about a failed delivery system (The Phoenix Project) built ala WaterFall, versus a new system hastily assembled (heh, see what I did there?) on an impromptu assembly line and delivered in record time, performing brilliantly - when compared to the failed behemoth Phoenix Project.
So... here's the problem with DevOps, and the problem with this book.
Companies with a nightmarish legacy code base (delivered or not as-of-yet out the door) that are attempting to build DevOps are using the same people that created their behemoth nightmare in the first place. As does the company in the hypothetical story in the book. Worse. The CEO in the book is a horribly bad boss, making wrong decision after wrong decision (I am sure to ramp up the tension to illustrate the saving graces of DevOps). So, I can tell you definitively that ANY company with leadership like that would lose their brilliant techs almost immediately. The market is in desperate need of brilliant techs so there is zero possibility that they are going to stick around a cess pool of politics when they can get a signing bonus and a raise from a company already doing it better and faster, and all without the drama. I'm just saying. And in order to pull off a DevOps operation, you absolutely need brilliant techs. You need tight, well executed product code with sufficient testing hooks so you can automate as you go. So you need brilliant QA that can understand and/or code the hooks right along-side the devs.
In short, you need a whole lot more than a single Brent. You just do. And to imagine that there are a room full of brilliant techs writing broken down shoddy bloated code for Phoenix, but then can turn around and write the brilliantly architected code you need for the DevOps project... well... I am able to suspend belief when called upon, but this was more like taking it out back, shooting it, and burying it six feet under. I'm just sayin'.
And with that being said, I am a huge, ginormous fan of DevOps (and the book was a FUN read / listen, thus the 4 stars instead of 3). It just takes an incredible talent pool to pull DevOps off and books like this makes companies think they just have to implement this process with the talent they have and poof! instant quality software that can be delivered instantaneously! Woohoo! <sighs> They would be better served facing the reality of the mess they have, caused by (possibly) a lack of reasonable process, yah, but almost certainly by lack of talent as well. That's basically how they got where they got.
Off soap box now. Doing the tango. Eating Oreos. Feel free to join!