What do Chevy V8s and DevOps have in common? They’re both complex systems with many interactions between their moving parts.
The first time I did minor surgery on a Chevy engine I learned a lot about systems. The engine was a tired 283 cubic inch V8 in a 1966 Chevy Malibu which my grandfather purchased new in 1966 and passed it on to my (much older) brother around 1980. During my brother’s ownership it was driven hard and received a less than flattering paint job. By the time it was passed to me it ran about as well as it looked, which is it say it was rough. A buddy of mine who thought he knew something about engines convinced me to replace the valve train with parts from a junkyard. The results were not good; we only succeeded in making it run worse.
Interchangeable Parts
The problem was that valve train components are not interchangeable after they wear-in. Sure, when they’re brand new the parts are interchangeable. But after a while the parts wear together and become fitted to their neighbor. Had I better understood this complex system I wouldn’t have expected old valve-train parts to improve the engines performance.
In “The Phoenix Project”, we are encouraged to think of DevOps as an interconnected system, in the same way “The Goal” taught us to think about manufacturing processes. In an interconnected system, the parts have to work together with precision to achieve the goal. In DevOps, we talk about shortening cycle-time and increasing release frequency, requiring Dev and Ops processes to work together with precision timing.
Unexpected Results
How many times have you made a change to something (anything) and afterwards thought to yourself, “That didn’t go as planned”? I know I have had the experience on more than one occasion. Taking the time to understand the system is hard, but it pays off over time. Just as Erik in “The Phoenix Project” reminds us, “…Step 1 is to identify the constraint”.
Be mindful of the system and seek to understand before suggesting improvements. Failing fast and fixing twice makes sense when talking about features, but not so much when talking about system availability.
Getting Better All the Time
Embrace the system of things… seek to understand the interaction between the moving parts. Try to be aware of processes that have become fitted to their neighbor and what will happen if just one of those processes is changed. Avoid the urge to suggest changes without first understanding the system.
I got better at rebuilding engines as I learned the underlying systems. Knowing the systems allowed for changes that improved performance. Understanding the tradeoffs in the system was also important; an engine tuned to develop maximum horsepower at full throttle will run rough at idle.
Take the time to understand the interconnected systems we are attempting to improve.
