Book Review: The Unicorn Project
Book Review: The Unicorn Project
This article reviews some of the essential concepts of the recently-released DevOps book from Gene Kim, The Unicorn Project.
Join the DZone community and get the full member experience.Join For Free
In November 2019, The Unicorn Project by Gene Kim was been released. The book focuses on the development part of The Unicorn Project of Parts Unlimited which was introduced in the well-known book The Phoenix Project. I finally had the time to read it and share some thoughts about it.
The Phoenix Project is a standard when we are talking about DevOps books. It is written as a novel and focuses on key DevOps concepts. The protagonist is Bill Palmer, VP of a company called Parts Unlimited. If you have not read The Phoenix Project yet, you should definitely order it now or read one of the previous posts where you can read a book review. The Unicorn Project was already mentioned in The Phoenix Project as a project where the developers could start anew and use best DevOps practices without the struggles of the Phoenix Project. In this new book, Maxine, a female senior software developer, is the protagonist. It is the same company, the same story, but now seen from a development point of view.
It all starts with a severe outage and someone must be blamed for this. It appears to be Maxine, although the outage was not her fault. As a consequence, she is banned from the Phoenix Project. I will not give a summary of the book, but I want to share some thoughts, information which I think are important or recognizable.
A very recognizable story is about Maxine asking the helpdesk for a development environment. It is a real struggle for Maxine to get what she wants. She notices some moment in time that the ticket she created has been closed. In the activity log of the ticket she reads that several people have taken a look at the ticket and in the end, it is being closed because it needed manager approval.
Her next step is to create a new ticket with an e-mail containing the approval of her manager. She is astonished when she notices that this ticket is also being closed because the approval had to be done via the ticketing system and not by means of an attached e-mail. In this case, the helpdesk chooses to follow a strict process rather than to really help the person who created the ticket (isn’t that a violation of one of the Agile principles of the Agile manifesto: "Individuals and interactions over processes and tools"?). Besides that, the helpdesk employees have no idea of what Maxine actually requested.
I also quite often notice that helpdesk employees do not have any affinity for software development and that they are more used to delivering standard office IT. We, as software developers, should not take for granted that a helpdesk employee has software development knowledge. Therefore, we should talk to them and explain what we expect from them.
On the other side, if a helpdesk employee does not understand a certain request, then we may expect that he or she will come back to us in order to request some clarification. And finally: do not use a ticketing system for communication, take the phone or go and meet each other.
Reducing Technical Debt
Another part is about reducing technical debt. Technical debt is similar to the necessary maintenance for your car. If you are not maintaining your car regularly, you will run into problems in the long run. If you are not reducing your technical debt regularly, implementing new features will take longer over time, or worse, the developers do not dare to change certain parts of the code anymore.
A major problem is that the business only requests new features and are not interested in reducing technical debt. It is, therefore, very important to demand time for it and to explain to the business how necessary it is to pay enough attention to it. A very good article is written by Martin Fowler that addresses this is, "Is High Quality Software Worth the Cost?"
It is difficult to change things in the Phoenix Project. It is decided that Maxine joins a separate team that can go their own way. This team can introduce necessary changes like CI/CD, automated tests, and work together with the business and the test team. A lot of waste is present in the current working processes, which means that there is a lot of waiting time. This waiting time needs to be reduced by introducing fast feedback loops in order to learn fast.
People tend to think that when something is difficult, you should do it less often. However, the opposite is true: the more difficult something is, the more often you should do it. A common example of this is release deployment. When it is difficult to release, people tend to say that we need fewer releases. Fewer releases often mean bigger releases, increasing the risk of failure. It is better to release often with fewer changes; this way you will practice more how to release and you can learn faster, eventually reducing the risk of failure.
The Five Ideals
The Five Ideals run like a thread throughout the book. Because of their importance, I list them here:
- Locality and Simplicity
We need to design things so that we have locality in our systems and the organizations that build them. We need simplicity in everything we do, in our code, in our organization, and in our processes. When you need to make a simple change and you need to change 15 files instead of 1, then you are probably violating this ideal. This is also known as the Single Responsibility Principle.
- Focus, Flow and Joy
How does our daily work feel? This means not waiting for other people in order to get things done, and getting fast and continuous feedback. Also consider the lunch factor (similar to the truck factor): how many people do you have to pay lunch for in order to execute a deployment?
- Improvement of Daily Work
The Toyota Andon cord is a good example of this ideal. Sometimes, processes are improved by adding an extra step to the process every time something went wrong. This way a bloated process is created which negatively impacts flow. Often, when suggestions for improvement are made in a team working on a legacy application, the suggestion is killed by saying, "We have always done it this way." Of course, this is a non-argument. You must judge the suggested improvement and not express your feelings against change. This ideal is also about reducing technical debt which we discussed already. This way it is impossible to have fast feedback and it can have a devastating result for your company.
- Psychological Safety
There should be no blaming culture, and it should be safe to talk about problems and how to solve them. A culture of fear will make people hide their mistakes, while a culture of safety will ensure that things will improve.
- Customer Focus
Are we working on something the customer is willing to pay for or is this a feature which only will satisfy a functional silo? In other words, we need to focus on customer value.
Some references worth reading, listening, viewing are:
Just like The Phoenix Project, The Unicorn Project is a must-read for everyone who is involved in software development. It won’t take long before this book becomes a standard in the list of DevOps books. So, go out to the store, buy it, read it and practice it.
Published at DZone with permission of Gunter Rotsaert , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.