The original post was on "The Phoenix Project" Must Read For Developers - Reading Time: 4 Mins and cover image by Lenny Kuhne on Unsplash
Introduction
When it comes to DevOps, I believe there is like two books. That proved to be quite beneficial & inspiration that feels like the holy bible level in the DevOps world which is The Phoenix Project & The DevOps Handbook
The first narrates a story about transformation for the IT department. From a traditional cost centre to value creation business unit. Much like how AWS was the brainchild of Amazon's IT infrastructure. Which developers or startups rely on it daily to build products or services on top of AWS.
The other book The DevOps Handbook was talking about the success stories, methodologies, philosophy and case studies. On how various companies or organisations have transformed their companies. By adopting DevOps philosophy or culture as part of their organisation. Which has nothing to do with any new fancy tools.
So if you had read till this portion of the article and you take DevOps seriously. You can get those two books for your library. But wait there's more, if you want to know why I feel it matters for every developer to read it. Please do carry on I would tell you why.
Understanding the Language of IT Operations & Lean Methodology
I won't be spoiling you on the book in the nitty-gritty part of it. To be honest, when I was reading the first 20% of the book. I was having memories of what I learnt for IT service managment classes in school. Yes, I was not trained as a developer but as a computer networking professional & IT technician. Who creates computer networks, managing computers & servers as well as repairing these computers.
It even brings back bad memories during my internship. Which I was attached to in a managed services department of a local telecommunications company. Who is handling the IT operations of an Australia bank.
I gain exposure to the world of IT operation and service management on their use cases and terminology for it. For this book, it came with a twist. Which is sending you down to a dumpster fire. Like a typical story that uses the The Hero's Journey. This is important as it lays the foundation for you to apply it.
Justifying Value for What You Do in the Eyes of The Users
In the book, it shows the reader about the process of the transformation from traditional IT operations. That is commonly viewed as a cost centre and a means to the end to the business. Which morphs into a value creator besides just covering the bottom line. It covers in detail on the type of value on a strategic level. Through a series of probing questions of the users or people by each character. To figure out the importance of delivering value. Who are using the software to solve their problems or pain point they encounter daily.
Therefore we should frame it in the way, the users can understand how we provide value to solve their problem. Instead of just being a stepping stone. As a means to end in delivering the products or services to the customers. This is hugely neglected by our developers. If there is no established direct feedback channel from the customers.
Unless you are a customer service, who talks to the users or people who uses your products or services. This is the same concept that we should present as developers as a story to solve their painful problem. When we are talking to people. Who would be using our software as a service or product to solve their problem.
DevOps is Not About Tools but Philosophy, Principles or Practices
As you dive deeper into the book, there won't be much mentioning of the tools being using. Instead, there are scenarios where principles, practices or process has to be established or adopted. So that anyone can operate and solve problems or situations on the spot. By leveraging upon past experiences to improve the effectiveness & efficiency of their operations.
Which hopefully for your case, there will not be a single person hoarding all the information or knowledge. Who is treated as a goto firefighter for all fires without writing down how it is done. So others can learn from the experience. As firefighting is not the person's main job. If it is on a daily basis, there is something seriously wrong with your organisation.
While firefighting can be glorious but highly ineffective in the use of our time. We could have spent more thought in applying infinite game thinking & documenting the firefights we had. To focus on prevention & risk avoidance through practices we adopt. Setting up the processes or writing down the firefighting experience. Which reduces or prevent the repeat of the same situation happening again.
Conclusion
I hope that I could convince you to read the book on The Phoenix Project as it provides you digestible way. For you to understand & apply it to software development. Before you think about adopting tools like Docker, Selenium & Puppet for a smooth deployment & delivery for the users to use it. This allows you to think on a strategical level. Regardless of your job title, within the organisation.
Personally, I had encountered many real-life situations. Which is vaguely similar to what the characters in the book had done. Like an ex-colleague, who does not deploy use shell scripts to deploy on either testing & production server.
AS the person thinks that the person will not remember or how to fix it when problems occur in the deployment process. Which makes me remember a particular character of the book. Who was a firefighter in the book that does not document their situation after each fire has been exhuasted.
Lastly, are you looking to specialise yourself as a developer? If it's a Yes. I'm giving away my free ebook called "Picking Your Specialisation as a Developer" for anyone interested to command a higher salary or do the work that you like.
This post includes affiliate links, I may receive compensation if you purchase products or services from the different links provided in this article.
Top comments (14)
The follow up, The Unicorn Project is a great addition to this. It gives a new insight into Parts Unlimited and the politics of the time.
π I'm still going through the book "Phoenix Project". I might take a while for me to complete reading it.
Its the same story but from the point of view of one developer when she is transferred over to the Phoenix Project to serve as temporary scape goat for the latest systems failure. I read both books. Would recomend for any devs out there. If you have to choose which to read, as a dev read The Unicorn Project.
Nice alright I'll look at it. Looks like my number of backlog of books is increasing.
Tell me about it!
Also The Toyota Way is next on my list!
Awesome i really like it as they the poster child which inspired the agile movement for us due to their lean manufacturing concepts.
You should check out Accelerate then. It's a less fun read than the Phoenix Project, but it explains the methods the State of DevOps reports use to determine best practices. It's the kind of book that will help you determine what the next, best practices are when the DevOps Handbook falls out of date.
Yup I subscribe to the Puppet's state of DevOps. It's good. I have not heard about that "Accelerate" book, is it by the same author or someone else?
Two of the authors of the DevOps handbook partnered with Nicole Forsgren to write the book - it's available here amazon.com/dp/B07B9F83WM/ref=dp-ki...
Nice it was not in my purview I will take a look that.
He is one of the authors of the book.
I work "in DevOps" and The Phoenix Project is required reading for anyone who wants to be a DevOps Engineer. It's super fun and you get to work with a lot of cool tools, but everything you do has to bring some value.
In fact, when disagreeing with another DE about something, the easiest question to ask is "what value does this provide?" If they can articulate why, the we'll go with it. If they can't, then they understand why the solution wasn't the right choice at the time. This also provides opportunities for collaborative development of best practices and is overall a positive for the team, IMHO.
The best part of working in DevOps is that you not only get to improve the lives of developers with efficient pipelines and self-service tools, but you can actually improve the entire company.
Anything that makes the business run more efficiently, faster with less labor, or eliminates toil will ultimately allow the collective efforts of the teams to produce better software faster.
DEV user @pirxdanford does a great job of explaining the CALMS model (previously CAMS) which is the guiding principle of DevOps, IMHO.
dev.to/pirxdanford/calms-a-holisti...
Yes that's great!! Cause sometimes I wish there were more developers or DevOps engineers who reads it. Like for example of my ex co-worker, he literally took whatever my senior software engineer says. As words from God but did not think about it. To make it easier to work on deploying it into our testing and production server but choose to do everything manually without scripts to automate it to reduce the time taken.