The most precious resource we have is time. Its most irritating aspect is not knowing exactly how much of it we’ve actually got. We can’t get any more of it. We can’t save it, we can only spend it. We expend a great deal of energy and effort trying to figure out how to spend it wisely, and on which things. It can be overwhelming.
DevOps, a phrase coined by the tech industry, is set of problem-solving patterns to help light the right path forward. To be clear, DevOps is not new. The technology industry loves taking old ideas and taping a new name to it and pointing, “look what we made!” DevOps is old. It’s as old as, well, time. Humans have been doing this for a while now. Technology has just shortened the feedback loop to a point where we can observe small changes.
What is DevOps, anyway?
Ask five people for a definition of “DevOps”, and you’ll likely hear five different answers. It’s a culture. It’s a job-title. It’s “development plus operations”, and people need to be able to do both (this is rare). I’ve even heard it used as a verb: “We have to DevOps that.”
There’s a wonderful metaphor of a group of blind people touching an elephant. They can only touch a small part of the overall animal. The tail. An ear. A foot. The animal’s trunk. The blind person thinks their individual part is the elephant, and disregard other observers’ ideas because they don’t match.
DevOps is the elephant.
At a high level, DevOps is a framework for managing risk to our time. Its patterns help us focus our efforts. It forces us to ask questions. Good questions. Humans have been doing DevOps since before computers existed. There was ancient DevOps. They were doing DevOps when they built the pyramids. Risk is everywhere. Humans can manage it without computers. Computers just make the process faster, and allow us to observe smaller changes over a much smaller window of time.
Effective DevOps seeks to answer four questions
- How do we make our stuff?
- How do we know it works?
- How do we change it without losing our minds (or our customers)?
- How do we learn from our mistakes?
It’s the Cycle of Awesome.
DevOps is a process for improving the trajectory of the Cycle of Awesome. It’s a framework for improving our craft. Improving things requires change. Change is inherently risky. We want to make it better, but sometimes we make it worse. DevOps is a framework for managing this inherent risk. This can be applied to just about any industry. DevOps patterns can be found in Computing/Agriculture/Medical/Space/Financial/Software/Yarn/Toothpick production.
We improve the trajectory by asking questions. I like to “what if” around the edges of an idea. It’s better than prescriptive statements, like “do these 10 things and you’ll be amazing!” Recipes are great for baking a cake. They’re not so good for dealing with complex, uncertain environments. We want good outcomes, and a recipe demands a certain set of circumstances before success, and worse, a specific outcome.
By the way, “focused on a particular outcome” is one of the seven factors of stupidity. Sidebar:
“Stupidity is overlooking or dismissing conspicuously crucial information.”
— Adam Robinson
7 Factors of Stupidity
- Information overload
- Outside circle of competence/environment
- In the presence of a group
- In the presence of an authority (can be yourself)
- Stress — emotional, mental, physical
- Intense focus on a particular outcome
Next time you’re evaluating something to find gaps or potential for errors, ask yourself how many factors of stupidity it satisfies.
Back to DevOps:
Life rarely works out like a recipe. It’s better to operate with a set of patterns when puzzling through problems, than a specific step-by-step “do it this way” approach.
Here are some questions to help inform the patterns of DevOps, and keep us from doing silly things and wasting time:
How Do We Make Our Stuff?
- Can we build and improve it efficiently? What does the development tool-chain look like?
- Did we pick a technology we can hire for, or did we choose an esoteric thing because we thought it was cool?
- How easy is it to reason about what we’ve built? How long does it take a new person to ramp up on our stuff?
- Can we scale it without burning through all of our operating capital? For instance (in software), does it require a giant machine to run on, or can we run it on a simple, cheap device?
- Do we invest in our resources? Do we invest in our people?
How Do We Know It Works?
- Are we monitoring it? What are we monitoring? Are we looking at the right things? Are we asking other people who have done this?
- How do we gather user feedback? How do we track it? Do we even pay attention to users?
- How can we tell when it breaks? Do we know the warning signs? What are the signposts to failure? Are our customers finding out what’s wrong before we do?
How Do We Change It (Without Losing Our Minds)?
- Did we design for change?
- Can we change it slowly, or do we have to change it all at once?
- Is our change easy to reason about?
- How fast can we go backwards?
- Are we recording what we did to change things?
- Is it simple, erasable, and audit-able?
How Do We Learn From Our Mistakes?
- Do we admit we make mistakes?
- How do we find out what happened? Do we even look?
- Look for the root cause. The reason something broke isn’t always on the surface. Have to dig for it.
- Can we tell who was affected?
- How do we spread our learning? Do we encourage our organization to hoard knowledge? Are teams in silos? How do we get them to talk to each other?
- How do we encourage experimentation? What is our tolerance for failure?
- How do we make it hard for ourselves?
So, Cycle of Awesome. It’s a feedback loop. You want it to be as short as possible. Tiny. Fast. The Cycle of Awesome should spin like a flywheel. If any part of this loop is failing, your trajectory will be flat. It might even go down. You want it to go up.
DevOps is a framework for prioritizing your time and effort. The Japanese have a word for it: “kaizen”. It means “improvement”. It can be applied to any type of business, any product.
Remember the Cycle of Awesome: how do make our stuff, how do we know it works, how do we change it, and how do we learn from our mistakes. Keep improving all aspects of the cycle in your work. It applies to everything. Spend your time on the right things.
Thank you for spending some of your time with me!