blog/content/reviews/books/the-phoenix-project.md

+++
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](https://www.goodreads.com/book/show/17255186-the-phoenix-project):
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.

<!-- more -->

{{ 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.