That statistic is even more surprising when you learn that in 2018 there were 23 million software developers around the world
These numbers mean two things:
- Good Software development practices are a must
- There are a lot of opinions on what “good development practices” look like, and navigating those opinions can be challenging
There are however also a few individuals in the Tech Field who often share their opinions on software development in the forms of interviews, blogs, and books, (Martin Fowler or Kent Beck for example) whose opinions are often seen as valuable in the Software world.
One of those people is Founder and longtime CTO of Tripwire, Gene Kim. Mostly known for his books, Kim has had a profound impact in his career on the outlook on the importance of Software Development Practices. Many are familiar with the books he has written or co-written: The Phoenix Project, The DevOps Handbook, Accelerate, and were delighted to see his newest release The Unicorn Project.
While The Phoenix Project focused much on the DevOps / Infrastructure side of Software Development, The Unicorn Project follows Tech Lead and Architect Maxine as she tries to navigate the challenges of ever changing requirements and external dependencies in her Dev Team. In Phoenix used “The Three Ways” and the “Four Types of Work” to describe important concepts which many use to help define DevOps today.
In this article I would like to share the key takeaways from some of Gene Kim’s finest works.
Takeaways from The Phoenix Project:
Written in the form of a novel with made up characters and story line, The Phoenix Project follows IT Manager Bill as he tries to deal with the expectations to go faster and the communication and dependency challenges that many teams have. It illustrates how the “DevOps” movement can be used to transform teams by following the underlying principles of the movement, described as the Three Ways:
The Three Ways:
The Principles of Flow
illustrates IT as a value stream. Almost like a factory line, where each component adds value to the line with the expectation that it only has to be done once
- Work flows in only one direction — downstream
- Defects are never passed downstream
- We should always be trying to improve the flow
The Principles of Feedback
used as a way to measure the value added by your stream
- An upstream feedback loop should be in place
- The feedback loop should be as short as possible, meaning quick feedback on additions/changes
The Principles of Continuous Learning and Experimentation
describes the culture and environment of a software organization
- Seek to master things through practice
- Learn from success and failure
- Promote experimentation rather than fearing it and the possibility of failure.
The Four Types of Work:
- Business Projects — these are the projects your Stakeholders ask you to do for customers
- Internal Projects — an example of this would be migrating from a locally hosted data center to a cloud provider
- Operational Changes — this could be something like deploying new features
- Unplanned Work — failures, bugs, or sudden changes in plans which require immediate action.
Takeaways from Accelerate:
Written as a result of research done in the State of DevOps Report which is a survey filled out by companies around the world of all sizes, Accelerate published the Four Key Metrics which the researchers determined are the only differentiators between low, medium, and high performing teams:
The Four Key Metrics:
- Lead Time for changes — amount of time between a customer or stakeholder making a request, and that request landing as code into production
- Deployment Frequency — how often changes are deployed to production
- Mean Time to Recovery — how long it takes to recover from a discovered failure
- Change fail percentage — what percentage of your changes cause an error, failure, or bug in your system
The metric measurements between low, medium, and high performing teams are divided as follows, with the leftmost column being a high performing team:
The Phoenix Project and Accelerate helped to set a basis, which many teams are still trying to adapt, on which Software Development Teams can measure their productivity and efficiency while directly having an understanding of how they can improve in those areas.
Takeaways from The Unicorn Project:
With the release of The Unicorn Project, Gene Kim has expanded upon his ideas of Software Development to identify what he considers to be the most important challenges impacting engineering and business today. He frames these challenges under what he calls “The Five Ideals”. Similarly to The Phoenix Project, the book is written as a novel with different stories and scenarios to illustrate these learnings and confirm the importance of the DevOps movement as a way to quickly and more safely deliver software.
The Five Ideals:
Locality and Simplicity
This relates to what degree a development team can make a local code change in one or more locations, without impacting or needing various other teams and other locations. We all know that being able to do things on our own without needing others to help us or provide something for us is easier. Needing coordination from multiple teams to deploy or develop a new feature only results in delays and potential challenges as a result of miscommunication.
In order for this to work, we need simplicity, meaning that parts of a product or software itself is loosely coupled from others and is kept as simplistic as possible in its implementation and infrastructure.
Focus, Flow, and Joy
A developer’s daily work and the way that work feels directly impact how effective that developer is. When developers can focus on writing code without delays or dependencies, it creates a sense of Flow and therefore joy. From the book:
“Is our work marked by boredom and waiting for other people to get things done on our behalf? Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during a deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? “
Improvement of Daily Work
This ideal is directly related to technical debt and architecture. The largest companies in the world (often referred to as the FANGs: Facebook, Amazon, Netflix, Google, etc) are as successful and consistent as they are because they make a conscious decision to get rid of the tech debt they have. Microsoft is famous for a culture which says if a developer has a choice between working on a feature or improving developer productivity, the choice should always be developer productivity. A great quote from the book:
“Amazon likely spent over $1 billion over six years rearchitecting all their internal services to be decoupled from each other.”
As shown in not only the State of DevOps Report, but also the Google Aristotle Project a culture where members of team feel safe to make mistakes and learn from them, and to take risks is important to the effectiveness of a team. This is because teams need to be able to talk about the problems they have and feel safe doing so, because prevention is required to solve the problems, which requires honesty and no fear.
As the name implies, this ideal reminds us to question if what the team is developing or working on is something that actually matters to customers (are they willing to pay us for it?) or is it only something that brings value to our own functional silo? If our daily actions are not providing value to the customer, maybe we should be working on something else.
Some of my favorite quotes from the book:
“Hoare principle: “There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it.”
“Punishing failure and “shooting the messenger” only cause people to hide their mistakes, and eventually, all desire to innovate is completely extinguished.”
“Creating software should be a collaborative and conversational endeavor — individuals need to interact with each other to create new knowledge and value for the customer.”
“Technical debt is what you feel the next time you want to make a change.”
These three books help to layout a sort of template or example which development teams can follow when working on projects and trying to increase their efficiencies, with many of the largest and most successful software companies already using these ideas. I am looking forward to the next book this guy writes.
What do you think? Is there something he missed?