On the Phoenix Project

I recently finished reading “The Phoenix Project“. As a senior software developer, reading this book has provided greater insight as to the inner workings of an IT department’s interaction with business.

Some of lines and developer jokes from the book:

  • “CIO stands for ‘Career Is Over.'”
  • “if your colleague tells you they’ve decided to quit, it was voluntary. But when someone else tells you they’ve decided to quit, it was mandatory.”
  • “If I fail, I’ll try to make sure it’s in a new and novel way.”
  • “for IT to keep the lights on. It should be like using the toilet. I use the toilet and, hell, I don’t ever worry about it not working.”
  • “Developers are even worse than networking people. 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.”
  • “We need to establish an accurate timeline of relevant events. And so far, we’re basing everything on hearsay.”
  • “A developer jamming in an urgent change so he could go on vacation”
  • “Situations like this only reinforce my deep suspicion of developers: they’re 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 two working together gives us means, motive, and opportunity.”
  • “You’ve probably heard of them: the Theory of Constraints, Lean production or the Toyota Production System, and Total Quality Management. Although each movement started in different places, they all agree on one thing: WIP [Work in Progress] is the silent killer.”
  • “Creating that predictability is what I’m most intent on instilling in my IT Operations group.”
  • “Despite all that work, I wish I could have done more to prepare. I force myself to relax, visualizing having a healthy and vigorous business discussion with him, walking out with everything I ask for.”
  • “We need to focus on the riskiest changes,” I continue. “The 80/20 rule likely applies here: Twenty percent of the changes pose eighty percent of the risk.”
  • “I’m concerned that we no longer have sufficient version control—we’ve gotten so sloppy about keeping track of version numbers of the entire release. Each time they fix something, they’re usually breaking something else. So, they’re sending single files over instead of the entire package.”
  • “there’s a huge memory leak, and that’s even without any users on it. My guys suspect we’re going to have to reboot a bunch of the servers every couple of hours just to keep it from blowing up. Damned developers…”
  • “Here’s the most amazing part: We made a huge investment in virtualization, which was supposed to save us from things like this. But, when Development couldn’t fix the performance problems, they blamed the virtualization. So we had to move everything back onto physical servers!”
  • “Phoenix website is leaking customer credit card numbers. They’re even posting screenshots. Apparently, when you empty your shopping cart, the session crashes and displays the credit card number of the last successful order.”
  • “I’ve been in software development for virtually my entire career. I’m used to everyone demanding miracles, expecting the impossible, people changing requirements at the last minute, but, after living through this latest nightmare project, I wonder if it might be time for a change…”
  • “I used to love this work, but it’s gotten so much more difficult over the last ten years. Technology keeps changing faster and faster, and it’s nearly impossible to keep up anymore.”
  • “Just how many times can you throw out everything you know to keep up with the latest new-fangled trend? I look in the mirror every once in awhile, asking myself, ‘Will this be the year that I give up? Will I spend the rest of my career doing COBOL maintenance or become just another has-been middle manager?”
  • “Yes! I see it now! It really is unplanned work! The fourth category of work is unplanned work!…unplanned work is recovery work, which almost always takes you away from your goals. That’s why it’s so important to know where your unplanned work is coming from.”
  • “Chester, your peer in Development, is spending all his cycles on features, instead of stability, security, scalability, manageability, operability, continuity, and all those other beautiful ’itties.”
  • “Solving any complex business problem requires teamwork, and teamwork requires trust. Lencioni teaches that showing vulnerability helps create a foundation for that.”
  • “Erik’s First Way. He’s talking about systems thinking, always confirming that the entire organization achieves its goal, not just one part of it.”
  • “Get humans out of the deployment business.”
  • “‘code commit.’ If I could wave this magic wand, I would change this step. Instead of getting source code or compiled code from Dev through source control, I want packaged code that’s ready to be deployed.”
  • “Messiahs are good, but scripture is better.”

Yes, this book rails on developers, but also managers and everyone in between. In conclusion, when faced with challenges like dealing with raging managers, tight project deadlines, or just stressful situations at work, the right way to react is always to communicate the right information across so that you come across as having a solution that brings results, instead of producing outburts of anger or other passive aggressive emotion. There are emotions, but they should be redirected. Frustration becomes desire, worry to concern and alarmed to curious.