Gene KimReseñas

Interesting read. Very thought-provoking. Food for thought with different look at how information technology integrates with business needs and goals. The use of the novel as a teaching tool is a good idea. This book is definitely worth a read.

Started reading .... but despite some interesting moments lost interest. Unfinished

This one is rather interesting book.

On one hand it tries to show how inter-departmental cooperation, especially between IT services and between IT and actual business can prove highly valuable and can speed up and stream-line the main business processes and business-supportive projects/processes.

On the other hand for the dramatic purpose, issues that take significant amount of time in real life are shortened to a ridiculous short time-spans and some teams are shown as very slow-movers and not very capable. Some IT departments are shown as especially ... troublesome.

So I understand some of the reactions to the book (I recognized myself in several characters).

In my opinion what this book does very good is to show what exactly DevOps is - improvement in overall organizational thinking and planning, striving to achieve more in smaller steps [remember those many sayings like brick-by-brick-you-get-a-house]. If everyone is working together, if everyone is motivated and aims for the same - success of the core business - everything can be achieved.

All in all very interesting book that tries [in form of a fiction instead of academic or professional-literature way] to give insights to the readers how things can be much easier achieved through DevOps approach. And funny thing is that all the lections presented are applicable everywhere - not just to IT.

Recommended to everyone interested in organizational and planning issues.

I dunno. It started out fun then became less fun.

This was a real slog. The book leans heavily on stereotypes and cliches, and talks a lot about (awful) people's (awful) feelings, and needed a lot more editing. There are interesting ideas in there, but I think I would've been better off just reading the appendices (or maybe the DevOps Handbook, which is up next).

Could relate every page of the book as I was once a configuration and release manager.

This is a superb fictional book about a recently promoted VP of IT Operations, the challenges he encounters in the dysfunctional organisation he is in and how he turns IT around to be efficient and flexible. There are lots of great pearls of wisdom throughout with lots of manufacturing analogies. An easy read.

A sequel to the The Phoenix Project, focusing specifically on DevOps transformation (integrating IT management, software development, and IT operations). You'll learn:
• The challenges faced in traditional IT setups, and how DevOps can help to overcome those challenges to significantly improve the quality, reliability, security, speed and efficiency of IT solutions for both internal and external customers.
• The history, concepts and theories behind DevOps, as well as the 3 core DevOps principles (the “Three Ways”): Principles of Flow, Principles of Feedback, and Principles of Continual Learning and Experimentation.
• The step-by-step process to create your DevOps transformation, including: how to apply the 3 sets of DevOps principles and technical practices in your organization, and integrate QA and InfoSec into each step of your technology value stream.

Book summary at: https://readingraphics.com/book-summary-the-devops-handbook/

This was recommended at work and as a newbie to the IT world I can easily see why.

Coming into the 2020s in IT and it seems like a lot of these processes outlined are the norm (i.e. Kanban boards, CI/CD pipelines, Agile etc) but I found it instructive to understand the original problems these processes were trying to solve. It certainly seems like a nightmare in many respects and you end up relating with Bill a lot with his current predicament. I am especially glad that I read this book after joining an actual mid-sized company because otherwise a lot of the insights would've been wasted on me. I just wouldn't have much relevancy for them in my mind if I was working alone or in a very small company.

The book's novelised format was the other main selling point for me. Just like with The Cuckoo's Egg by Clifford Stoll, I find that books like these are rare - an accurate portrayal of an insightful real life scenario packaged in an enjoyable novel (and novel!) format. You're learning a lot by seeing these principles actually applied by a protagonist.

I have already set aside Goldratt's The Goal in my TBR after seeing it recommended in this book, and I'm excited for it!

If you work in IT you need to read it.

I ended up enjoying this a lot more than I thought I would. Which is amazing, because the first third of this book stressed. me. the. fuck. out. So many outages and shortsighted management decisions that triggered some PSTD from being in operational support. Otherwise it was an entertaining read that laid out the principles of DevOps well enough that I think just about anyone could understand them. My only issue is the turnround that Parts Unlimited has is miraculous and seems to occur in like three months. What a fantasy! I guess no one wants to read about book about three years of methodical IT improvements.

"Improving daily work is even more important than doing daily work."

Second time but this time on audible
Its fantastic exercise to think "what would you do if you are the main character in this book".

There are some interesting and useful things, but overall I didn't like it. I would not give this book one star, but ratings are this way. There are just too many things that are not true or exaggerations to say it was ok.

The single thing that I was more angry with was with continuous liking of it to a factory operation. Of course there is a lot to learn about how factories work, but we have spent years trying to avoid that comparison, because ours is intellectual work, and everybody has a different set of skills and we are not interchangeable, and our work estimates are difficult to make and are never, ever being to be exact. Every attempt to improve is welcome, but liking thinks that are not alike is not the solution.

All in all, I could say another things I didn't like about this book, but I will let the review as it is. Also, I don't know anybody who's gone from IT to being COO, if it is not in an IT company.

Aufgrund hymnischer Amazon Bewertungen und Nennungen auf Security Konferenzen habe ich mich zu diesem Buch hinreissen lassen. Es Roman zu nennen ist leicht übertrieben.
Im Minutentakt wird in Form eines Bullshit-Bingo jede verfügbare Business-Sau durchs Dorf getrieben, die auffindbar ist. Bei Begriffen wie Lean-Management, Kanban, usw. riegelt mein Gehirn automatisch ab. Etwa so, wenn die Zeugen Jehovas vor der Tür stehen und mit mir über Glück reden wollen.
Abgesehen davon, dass dieses Buch aus literarischer Sicht Mist ist, eine Beleidigung jeden Intellekts und in der Tat ein Sachbuch - ist es aus soziologischer und sozialanthropologischer Sicht dennoch interessant.

Ganz in US-Manier erinnert sich der Protagonist immer an seine lehrreiche Zeit bei den Marines und vergleicht diese mit dem Business. Gearbeitet wird grundsätzlich immer bis zum umfallen. Nächtelang durch, alle sind topmotiviert - Anrufe werden während des hinlegens der Kinder angenommen und zeitgleich werden bei der Gutenachtgeschichte Firmen-Emails gecheckt. Das ist alles so selbstverständlich wie der Otto-Normal-Ami eben keine Krankenversicherung hat. Ayn Rand lässt grüßen. Wochenden mit der Familie fallen eben mal aus, weil es einen "Sev-1 Vorfall" gibt. Bei der Erwähnung von Rüstzeiten und Taktzeiten am Fließband fühlt man sich endgültig in die industrielle Produktion des Fordismus zurückversetzt.
Leid kann einem nur der US-Amerikanische Leser tun. Der hat zwischen O'Reilly Fachbüchern und diesem Schmonzes nur mehr die Wahl zwischen Harry Potter, Ken Follet oder seichten Krimi/Thriller/Fantasygeschichten mit bunten Covern.

I still believe this is one of the best IT books available. And it's not about IT essentially, but about business, because what in business can nowadays go solely on its own, without the help of IT. Nor is it a book about developers, but about getting their work to the customer. Last but not least, I bet this book is extremely revealing for management people.

And the story is so funny and engaging!

Summary (incomplete):


Chapter 1

Bill Palmer finds out at short notice that he has been promoted to the role of VP of IT Operations. Attractive as it may seem, Bill wants to reject this offer. He has been working at Part Unlimited for 10 years, he is extremely busy managing one of the most versatile projects of PU, and the guy he is going to replace in the new role has just been fired without any preparation together with the CIO. PU, a $4B company, is sailing through stormy seas, and the competition is close to getting them out of the business. The CEO of the company cajoles him into accepting the role, and the most critical part of the quest is leading Project Phoenix, the success of which might bring PU back on the right track.



Chapter 2 & Chapter 3

"Show me a developer who isn't crashing production systems, and I'll show you one who can't fog a mirror. Or more likely, is on vacation."

In his first day as VP of IT Operations, Bill Palmer is assigned to resolve a glitch in the payroll system: all time-keeping records of the hourly employees are corrupted and their monthly pay amounts to 0. Not to mention that the payrolls have to be sent that very day. All problems that you thought to be only in your company, start to take shape. Bill is not able to fix this first assignment, and although he does a great job to separate the noise and establish the real cause of the problems, the news that Parts Unlimited failed to pay some of the employees makes it to the front page of the local newspaper.

The managers that Bill is going to manage directly and that are probably going to be of great help to him appear on stage. Wes, the Director of Distributed Technology Operations, an outspoken, hot-headed man who. In contrast, there is Patty, the Director if IT Service Support, a levelheaded manager obsessed with processes and at the same time aware of people's inclination to disregard things alike.

Going back to the typical problems in an IT department, there are the people in the finance department who are changing payroll data outside the payroll application, something both dangerous and error-prone. There are the marketing people who promise the world to the customer, while the IT department has to find out how to get it done. The management of change is present by means of some tools that everybody ignores. Often times, developer change the software in production, all in a hurry, because they are on vacation the next day. Last but not least, there is the omniscient, most skilled, most reliable engineer, called Brent in this book, who is able to repair any problems that no one else is able to, becoming a SPOF for all the projects of the company. Obviously, this guy is a critical, but utterly overloaded resource. On the stage also appears the manager in charge of Security, who is often sending list of patches to be added with the highest priority, whom people learnt to ignore, and who is applying therefore the patches himself, sometimes breaking a few things in production because there is no test environment (for budget reasons, of course.)



Chapter 4 & Chapter 5

We are done with the exposition, and the rising action starts to develop: there are two critical, not negotiable deadlines, due in less than a week, that Bill has to meet with the his IT team. First, the saviour project, Phoenix, has to be launched, even if the developers can't describe yet the systems needed for deployment. The launch can't be delayed, because of the business commitments to customers and to Wall Street. Second, an audit made by the financial department revealed up to 1000 breaches that remained unsolved for years now, and a response letter describing the plans to repair them has to be written before the external compliance commission arrives.

"The plot is simple: First, you take an urgent date driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date. The results are never pretty. Usually, the software product is so unstable and unusable that even the people who were screaming for it end up saying that it’s not worth shipping. And it’s always IT Operations who still has to stay up all night, rebooting servers hourly to compensate for crappy code, doing whatever heroics are required to hide from the rest of the world just just how bad things really are."

Wisely, the first step in such an apparently hopeless situation, is finding one what each employee is working on, so people's time can be spent from now on transparently and efficiently, knowing at any time what is the impact of changing schedules and pushing deadlines.

Fun and revealing story about life in the modern IT world

Strongly disliked the first two parts of the book, disliked the last part. The final process of Project Unicorn is one I've seen at work since I joined [$CompanyName] in 2013, and it works, but what do you do next? What's the next improvement or paradigm shift?

The characters are unlikeable, the writing is poor, and the 'story' is dull. If I had to work with these people, I would quit. Bill, the main Ops guy, is volatile, doesn't apologise after outbursts, and has this to say about developers in the first few pages:
“Show me a developer who isn’t crashing production systems, and I’ll show you one who can’t fog a mirror.”
“[Developers are] often carelessly breaking things and then disappearing, leaving Operations to clean up the mess. The only thing more dangerous than a developer is a developer conspiring with Security.”
The snark and derogatory developer comments come every few pages. QA barely exists in this book, testing is crammed at the end of a waterfall process where the developers eat up all the testing time and say "it works on my laptop."

In Bill's view, security is an obstacle to be avoided, and audits and compliance are meaningless busywork. Ops are perfect and never make mistakes, they're just overloaded with work generated by the rest of the company, who are at best misguided idiots. There is one hero Ops guy, Brent, whom no-one can do without, because he is the only one who knows how to do anything.

Patty exists just to parrot back Bill's ideas in other words. The 'guru' Erik is cryptic, condescending, and he refers to business people as 'Sensei.' I've been studying karate since 2008 and no-one refers to themselves or each other that way.

It's a book worth reading, but with a bucketload of caveats.

I devoured this book.

I thoroughly enjoyed reading about a character from a company far far away ... who is in a similar workplace as me. I'm in my own small scale "Phoenix Project". The book is trying to send a message through the guise of a novel.... with the characters more like stand-ins for concepts/obstacles than anything else.

Only for very specific type of professional development, and already quite dated and mediocre as a story.

Couldn’t put it down

Really good story. I can’t believe a book about corporate IT made me feel so much. But the characters are compelling and the topic is close at to my heart.

I can just see myself in Bill’s shoes, not the competent cool under pressure part, but the feeling of having no idea what’s going on or how to fix it. It was interesting to read about IT from the point of view of manufacturing. My company is dealing with some of the issues addressed in this book which made it hard not to see comparisons between certain characters and people I work with.

All and all good book. It could use a second editing pass though, lots of small grammatical mistakes. But I’m definitely reading the the sequel.

A must read for it, leadership and devs.

Read for work, it was okay.

Meant as a morality play for managers ends up being a wish fulfilment power fantasy with mary-sue characters. I know it's America but I had no idea half the men in there did military service. Great work on keeping that 20 million strong army a secret. I was expecting Erik to turn out to be the protagonists hallucination or the DevOps fairy. Was disappointed. It's also pretty lame as a regular book.

If this had been published in the 90s it would've been groundbreaking (and wrong). Published in the early 2000s it would've been bold. Publishing it now is redundant. Terms like CI are so common you don't even need to explain the initialism.

I was severely disappointed with this book. It is NOT a handbook of any kind. This is pure evangelism aimed at managers. Also, very quickly, I realised how extremely narrow the authors' world is. Basically: web services. Almost every argument and anecdote is based on the confines of the crazy world of silicon valley and web startups.

Most of the content is highly repetitive and very broad, not going into any useful details. None of the caveats or drawbacks are considered, just pure hype. It is not nuanced.

The authors are not wrong (most of this is common sense and not some novel process), it's just not a very good book.