As Mr Spock would say, “Fascinating”
Star Trek gets a mention in this Screaming in the Cloud podcast discussion between Corey Quinn and Gene Kim about the latter’s books, both the Phoenix Project and mainly the Unicorn Project.
One of the questions about The Unicorn Project gets to the heart of the matter:
“Is this a book for technology leaders, or is this a book for developers?”
The discussion weaves around the answer: from viewing the books as love letters to functional programming (particularly Clojure) as well as those who have “struggled to escape spaces inside Makefiles” to those who make decisions in the daily business of companies.
And I feel that is really the point of the exercise. Who does decide?
Corey Quinn expertly dissects not only the creative process of making the books in the first place, but also challenges the academic assertions in the book – the 3 Ways of Devops (Flow/Systems Thinking, Amplify Feedback Loops, Culture of Continuous Improvement and Learning) as well as getting to the centre of the novelist’s processes – what are you trying to do with your daily work which makes those feel inspired to do their daily work?
There is, however, an element of hyperbole. Through the promotion of Gene’s DevOps Enterprise Summit there is a valid stumble between what is considered enterprise and SaaS startup territory. There is hype around getting business leaders to see that “Any investment you do, involves software at some level.” While it can be about “starting a revolution, creating a kernel of change” in an organisation, there is a clunky claim made that economic growth through levelled-up software engineering practice can save the planet.
Really?
And at this point, I come away with a taste that I feel familiar from the books.
Don’t get me wrong, I love the books and I love the message, I just want them to succeed.
Learn To Fix Yourselves First
My question is this: what actually happens on a daily business inside organisations which makes software projects go wrong?
If you’ve read the books or experienced the situations explained in them, then you’ll know what it’s like. It’s incredibly hard to change behaviour at an individual level. This is why both in these books and a lot of current literature, the onus is on creating small teams. Small teams can focus and make things happen.
But small teams don’t stay small teams forever. Bosses see success and want to replicate success like-for-life. The point is, though, you can’t.
No matter how we slice it – the 5 Ideals, the 4 types of work, the 3 Ways – these are good practices which can be forgotten in an instant.
Better than lists, better than reminds, is us all acting in a certain way.
Is decision-making truly devolved enough to make any of the things talked about in the book truly actionable?
While I came away from reading the Unicorn Project with enormous excitement and hope for the future, I also understand through experience how quickly excitement can be erased in the heat of the moment.
One decision can ruin a mood.
Daily decisions ruin moods.
Perhaps your standup this morning can be a place to address that? Rather than aiming high – at some invisible “cultural or business level” – we could all remember the spirit of the books in our daily lives.
Carrying that through all of our interactions will help us all build and deploy better code, faster. Then perhaps we can make the world a better place.