3.8 KiB
+++ title = "The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win - Gene Kim, Kevin Behr, George Spafford" date = 2020-01-08
[taxonomies] tags = ["books", "reviews", "devops", "phoenix", "gene kim", "kevin behr", "eorge spafford", "1 star"] +++
GoodReads Summary: In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they'll never view IT the same way again.
{{ stars(stars=1) }}
Let me take something out of the way from the start: This is a book with a fictional story, which try to explain the DevOps movement. And it age poorly.
If we start with the fictional part, you have some guy which is promoted to VP of Technology and suddenly have to deal with the integration of all the IT parts of the company (infrastructure, development, security, business).
Just to prove the point that any company needs DevOps 'cause every company is an IT company now, the story is about an auto-parts company.
And heck if the characters are not as cliché as possible, with a few absurdities: The infrastructure manager is a fat guy that doesn't care about his appearance; there is the "evil" manager that tries to put the blame on everyone else but herself; the paranoid security guy (although every security person should be paranoid, nonetheless), which surprisingly turns into a monk in the middle of the book. And then you have the magical "future board member" that knows absolutely everything about IT, but it is never asked if he wants to manage the IT department in the first place -- and trains the new VP even before becoming a board member, maybe out of purity of his heart, 'cause he's a "down to earth" kind of guy, but since he's filthy rich, he can do that ('cause, you know, rich people are really willing to take their time to help others).
The story is planned exactly to prove a point: Crisis emerge and are solved exactly in order to prove there is an order things are in the authors head -- which becomes clear in the "Handbook", a non-fictional part in the end of the book. There are three ways in the way an IT department accepts DevOps and surely all the events happen in the same exact order.
Another point: instead of the VP being the catalyst of the DevOps changes in the company, people around him start to move into DevOps without knowing: The manager lady simply brings kanban out of the blue, for example. And that "security guy turned monk", out of the blue, decided to bring the stakeholders into the discussion -- again, without the VP being the catalyst for it.
In the end, everything ends fine: The VP is about to become COO, the evil lady gets fired, everyone is happy, everything is going, the company is making huge trucks of money... And nothing bad every happened: All ideas worked flawlessly, there were not side effects, everything is happy, with rainbows and candies and balloons...
After the story, there is the "DevOps Handbook", which could be something usable, if it wasn't for what seems an attempt to produce more words with little content. There is a bunch of replicated stuff, like "a downward spiral" which keeps being repeated two or three paragraphs apart. You know that scene in "Up!", in the newsreel, which the news person says "Lutz promised he'll not return till he proves he's right", cutting to Lutz saying "I promise I'll not return till I prove I'm right"? That feels exactly like this.
Again, the book didn't age well. There is a lot of space for pointing out side-effects, removing the "THIS NEW THING WILL SAVE EVERYTHING!" tone of the story. But, for someone who's into DevOps since 2017, the story and handbook seems really outdated.