My thoughts on “The Phoenix Project”

I recently finished reading The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. Here are my thoughts about it:

[BEWARE: from here on, it is full of SPOILERS. I have warned you.]

It is a novel that speaks about a fictional company called Parts Unlimited facing for the first half of the book unfathomable problems, mostly IT problems but they quickly overflow into organizational problems and all of this results in terrible business’ performance. They suffer one IT misadventure after another, and you can’t help but sympathize for the poor protagonist who tries its best but can’t do much given the situation.

As expected they hit the rock bottom and from there they start climbing up, finally improving their IT processes, organizational processes, and ending with good business performance. And they all lived happily ever after.

My opinion: It is too long and distractive to be considered a technical book, you should just accept it for what it is, a nice (quirky) novel, somehow educational, and that will be appreciated most likely only by people working in IT. If you are scarce of leisure time for reading and you want just to get the IT essence of the book, I recommend reading only the chapter 30.

Chapter 30 — The final showdown of the ultimate destiny

In Chapter 30 there is the final showdown between the protagonist and the hippie (yet ex-marine) DevOps guru who dispensed cryptic advices on how to fix Parts Unlimited for the whole length of the book.

I always thought that nobody in the world will ever know who invented DevOps. Yes, maybe we know who came up with the word, but who came up with the practice first? Very hard to determine. Anyway, the hippie guru in Chapter 30 reveals how he got in contact with DevOps, even quoting a real conference speak:

“Oh, really?” he says, deadpan. “Let me tell you a story. Back in 2009, I was a board director at a technology company, where one of our engineers went to the Velocity Conference and came back raving like a madman, full of dangerous, impossible ideas. He saw a presentation given by John Allspaw and his colleague Paul Hammond that flipped the world on its head. Allspaw and Hammond ran the IT Operations and Engineering groups at Flickr. Instead of fighting like cats and dogs, they talked about how they were working together to routinely do ten deploys a day! This is in a world when most IT organizations were mostly doing quarterly or annual deployments. Imagine that. He was doing deploys at a rate one thousand times faster than the previous state of the art.

I have worked consulting government agencies, their deployment rate is not far from quarterly or annual deployments, reflecting retrospectively today it is an hell of a waste. But let’s continue, we are finally approaching my favourite sentence of the book, the one in bold about Continuous Delivery:

Allspaw taught us that Dev and Ops working together, along with QA and the business, are a super-tribe that can achieve amazing things. They also knew that until code is in production, no value is actually being generated, because it’s merely WIP stuck in the system.

A bit of context: they were talking before about manufactoring, in which case it is more observable that an unfinished item (WIP) is of no-use until it is finished. Likewise, software sitting in our version control system is usually of no use to the business until it’s deployed to production (or released to the market).

And then the chapter continue with some DevOps implementation tips for the protagonist, described at a very high level.

Final note: Kudos to the author for creating hype for his next book (The DevOps Handbook, should be released on October 2016) by making the hippie guru talk about it as his personal future project. I will definitely read it.