Review: The Unicorn Project ??????????

A Novel about Developers, Digital Disruption, and Thriving in the Age of Data

I'm not kidding, I was very excited to get my hands on The Unicorn Project. The first book from Gene Kim, The Phoenix Project was very influential in my thinking about DevOps. The first time I read it, I simply enjoyed the story and thought it bore a striking resemblance to development organizations I've worked over the years. But the second time I went through, I really thought about the "Three Ways" and how they crystallized the essence of DevOps. The idea of The Three Ways gets past all the buzzwords and popular articles that seem to latch onto some of the more obvious by-products of DevOps without ever getting to what really matters.

So, needless to say, I was thrilled when I got an email from the publisher asking me to review an early copy. Where The Phoenix Project zoomed in on a single development team, The Unicorn Project dives into the digital transformation of an entire large enterprise. Unless you're working in a development shop, it's very difficult to understand the incredible challenges posed by decades worth of old technology, entrenched teams, TWWADI (The Way We’ve Always Done It") attitudes, and various other layers of dysfunction.

The Story

Gene lays these challenges out through our hero, Maxine, who must navigate the organization with a fearless and relentless pursuit of a better way. As usual, Gene's description of software development culture and challenges is strikingly realistic. Any development team member reading this book will immediately feel right at home. Fair warning though, you may feel a little sick as Gene carefully outlines the worst aspects of software development teams.

As Maxine experiences challenge after challenge preventing good software from being delivered, she realizes that many of her organization's problems are self-inflicted. In fact, most of the problems are the natural outcome of traditional organizational reflexes. Management and all the best technical folks were assigned to building new features. All the other work was pushed to the side or left to the most junior team members. Even simple things like setting up a new developer with an environment where they can be productive became almost impossible. Over time, the standards and processes simply demolished people's ability to get anything built.

The Five Ideals

In the Phoenix Project, the organization is transformed by "The Five Ideals." Now that I've been through the book, I need to go back and study these. I'm confident that while I don't fully understand them yet, over time I will learn that these really are the fundamental ingredients of Enterprise DevOps. Right now, I can't do much more that list them and suggest that you study the book to learn more.

• The First Ideal: Locality and Simplicity
• The Second Ideal: Focus, Flow and Joy
• The Third Ideal: Improvement of Daily Work
• The Fourth Ideal: Psychological Safety
• The Fifth Ideal: Customer Focus

Functional Programming, Really?

My biggest gripe with The Unicorn Project is the pervasive promotion of functional programming languages like Scala and Haskell. Trust me, I understand the appeal. But I stopped getting worked up about languages decades ago. If you have a vision of what you're trying to create, a good developer can make it a reality it in any language. Code in any language can be inspiringly elegant or look like something a four year old made with glue and popsicle sticks. So much of this book rings true, but this seems strangely out of place and supported by one-sided arguments that seem theoretical and not field tested. Frankly, it's the manageability of the JVM and wide availability of libraries, not anything about the language itself, that pushed so many enterprises to build everything in Java for the past 20 years. Scala is currently in 30th place in the TIOBE Index of programming languages. Right behind Fortran!

I would have liked the book to provide more details about how to manage telemetry when the entire enterprise infrastructure is instrumented. And I would have liked to know how the teams keep their automated testing up to date as things change. And I really would have liked to hear more about security and how enterprise DevOps can generate assurance as part of the ordinary course of work. But we're going to have to wait for the next one. I, for one, can't wait.