Consider the First Rule: Inertia

In the beginning, there was calculus. And calculus kicked my ass.

In fact, three distinct attempts at calculus in college netted me a single, sad, yet passing D+. For someone who considers himself above average in intelligence, these were three semesters of pure, unadulterated stubbornness with intermingled graphic episodes of questioning my purpose on this earth.

Common sense would have had me quit while I was ahead, and switch to a major that didn’t require calculus. But stubbornness prevailed and I calmly registered for Calculus 2.

Though my friends thought I was going mad, given that I had simultaneously registered for Physics with Calculus. Given my previous lack of success in this course, this was the educational equivalent of lighting a match…

while standing next to a gas pipe…

that was leaking…

while wearing clothes doused in gasoline.

You see where this is going.

But I had discovered a secret. I’d figured out a way to make sense of the innumerable equations and rules of calculus thanks to learning a bit about physics.

Let me be clear here.  I did not magically get smarter that semester. What did happen was a conjunction of realizations about the rules of calculus and how they applied to the physical world. The world I could touch, feel, and experience.

Physics let me visualize what the calculus equations represented. Phenomena such as inertia, velocity, and acceleration allowed my brain to jump a chasm of mental blocks that prevented me from “getting calculus.” I could suddenly take complex equations and map them to physical problems. Even while I was in calculus classes, I was visualizing physics because the equations were the same. Physics was my Rosetta Stone to understanding calculus. All those weird curves on graphs now meant… something.

What does that have to do with DevOps? It’s not directly related, but I will try to highlight how thinking of certain DevOps concepts and measures as having physical equivalents will allow a better understanding of the methodologies as a whole. So, with that said, and to quote the great Inigo Montoya from The Princess Bride, “Let me explain. NO, there is too much. Let me sum up.”

There is a Physics to DevOps

While the industry has made great strides in finding statistical evidence of the effectiveness of DevOps, in its early days it was an esoteric belief. A decade ago, you could speak to business groups about DevOps and walk away with the very clear sensation that the room listened to half of what was said and understood about 2%. It was incredibly difficult to carry over the concepts to the real world.

In this industry, we spend significant amounts of time to gather business metrics that help us SIZE, WEIGH, TEST, MOVE, and EFFECT CHANGE on businesses. We use these measures to explain the benefit of streamlining and improving throughput in value streams. We speak to groups and explain the importance of t-shirt sizes and how planning less in advance, makes things faster and more efficient while throwing weights and measures of success in to prove our points. All this while some in the audience are still trying to understand the contradiction of how “planning less” equals “faster and more efficient.”

I find that many of the rules of physics correlate and support the concepts of DevOps in business. Let’s dive in and explore rule one…

The First Rule is Inertia

An object will remain at rest or in a uniform state of motion unless that state is changed by an external force.

This is one of the first classic rules of physics and is commonly stated as: objects at rest will stay at rest; objects in motion will stay in motion. Until something applies some form of energy to it. Slapping a ball out someone’s hands. Kicking a rock in a path as you walk by. Asking a team to change the way a business process is executed. Unless something happens, things will remain as they are.

It takes ZERO effort (aka energy) for the status quo to be in effect. That is why organizations and teams fall into the rut of saying, “that’s how we’ve always done it.” But changing a process isn’t always so easy as just asking. Leadership must understand how much MASS is involved before asking for a change.

I consistently find myself asking, “How big a LIFT is that?”

The bigger something is, the harder it is to move or change. But how do you measure the MASS, or “weight” of a business process? There are many possibilities but in DevOps we have called the technical/tools portion of this weight, Technical Debt. But there is also a weight to the corporate culture. Both sources, technical debt and cultural inertia, will cause organizations to expend energy to cause changes. More challenging is the realization that most organizations are blind to one or both of these weights because they are looking at their processes from inside with no external frame of reference. Their perspective is skewed.

It is a good idea to take stock and possibly address some of these weights before beginning a significant technology or process evolution as part of a larger DevOps initiative. It’s an even better idea to instill corporate/team practices that prevent these weights from becoming issues.  One example of this is the use of Post Incident Reviews with a focus on tracking fixes in backlogs.

One of the easiest to implement, yet least practiced processes to reduce technical debt is the Post Incident Review.  That fabled last step of every incident to go back and actually optimize code/infrastructure/processes in order to prevent the root cause from creating an issue again.  Instead, many organizations reach a stable state after the incident and do not go the extra mile to do a post incident review and identify remediations tasks to enter into backlogs or go through the process of creating, or updating, runbooks to help identify and resolve future incidents faster.  Performing post incident reviews and tracking remediation tasks to completion is a powerful move towards reducing technical debt.

Stay tuned. In subsequent blogs I’ll further reveal my perspectives on other ways the rules of physics relate to DevOps and provide some recommendations on some of the “low hanging fruit” to effect motion in your teams towards DevOps methods and practices.