The Unicorn project is the sequel to The Phoenix Project. I was excited to read the book when I heard about it because of how much its predecessor has influenced how I work. It is set more or less in the same timeline as the original at the fictional company Parts Unlimited, although the technologies and ideas involved are updated to resemble software development in the last decade. It also mostly focuses on different characters.

The main character, Maxine, has to deal with being the scapegoat for a high profile outage and reassigned from her comfortable, well-functioning team to her company’s disfunctional mega-project. This is project Phoenix, which will be familiar to readers of the previous book. In that book, Phoenix is a far off IT project that causes problems, but in this it is the focus for most of the story.

Phoenix is under the helm of a marketing person named Sarah who can’t understand that imagining a set of requirements is different from implementing them, or what is working or not. She has the Phoenix team on a death march and a few chapters in decides that they will just go live with a lot of half-baked features. That is, not a slimmed-down MVP that will deliver some valuable feedback early. All features are delivered, most of them in a state where everyone but her knows that there will be problems. The results are obviously disastrous.

It takes Maxine weeks to even get the code to build locally, and weeks to get anything deployed to production. Fortunately she meets a group who call themselves The Rebellion, who are intent on doing what they can - by back-channel means if necessary - to improve the output (and satisfaction) of the tech workers at their company.

This is all allegory, attempting to prove the value of a set of ideas:

  • co-located decision-making power (in people and in code) as opposed to spreading these out, which decreases understanding and speed
  • delivering small amounts of working code continuously rather than a big lump of poorly-understood code at once (continuous integration and deployment)
  • the astonishing difference that choosing the right technology for the job can make
  • the power of experimentation to find new ideas that generate revenue

Seeing the bibliography at the end, it’s clear that in addition to his experience of devops culture, the author has done meticulous research and consulted widely, so the ideas are mostly trustworthy. It’s also worth mentioning that the previous book and its companion, The Devops Handbook, are industry-defining works.

Unfortunately the delivery is poor: it’s somehow repetitive and slow while also giving examples too quickly. Buzzwords just magically make things better.

Most jarring is the mention of how important a NoSQL database is to a certain project. The example goes on and on about how it’s NoSQL that made things better, but NoSQL is not a specific technology. It’s a family of database technologies, united in the fact that they are not relational databases, but different in what they actually do: an object database, or a key-value store, optimising for reads or optimising for writes. This would have been far more believable if the author had explained the general point that NoSQL sets asides some of the traditional constraints of SQL databases, then explained what the constraint was, and used a specific tool like Redis, or MongoDB or Memcached for the example.

Slightly less jarring are the references to functional programming magically making things better, but that may only be because I know of more real-life stories that relate. Many teams in the Ruby on Rails world have switched to Elixir - a functional language - when they felt that their apps couldn’t handle the load they needed. When the peak load moments came around, they wondered why their Elixir app was operating with such low CPU load, to the point where they were searching for what went wrong. Unfortunately the Unicorn Project uses examples that are even quicker than what I just gave, and we lose any nuance about learning curve or what tool is appropriate for what job.

It may be that for a technology leader - who is at substantial distance from code and has been for some time - will find the book valuable as a way of expanding their awareness outside of “how we’ve always done it”, and trust their underlings more when recommendations for new technologies are explored. As someone who could well be that underling, I am actually pleased that a CTO who read this book might have heard of some of these ideas before we speak.

Apparently the book is a Wall Street Journal best-seller so presumably someone is finding the book valuable. Perhaps if I hadn’t read The Phoenix Project I would have felt like there was more that was fresh. As it is, I would warn people that the book may be valuable for the lessons contained, but that it is very hard work to extract them, and perhaps reading a few blog posts on the topics covered would be more valuable. Or go back to The Phoenix Project, and then ask someone to translate to modern software development.