Five years ago, before I worked at Nebbia, a co-worker told me he wanted to get an ALM certification. I stared at him and blinked.
“Application Lifecycle Management.”
I don’t remember my exact reaction, but I was skeptical. I didn’t understand what that meant at the time. My focus was entirely on writing the best, cleanest, most awesome code I could. All of the frustration with code that didn’t work, about sites that were down, about working late nights and clients that were less than satisfied sometimes, that just all came with the job. This was before I figured out it doesn’t have to be that hard.
Looking back, I realized I had picked up some pieces of the DevOps puzzle in my time working there. When I started, we had no source control and I understood that once we started using it (TFVC) it became much easier to work. Then, after seeing TFS updates being a pain for our IT admin, I convinced our company to trust the cloud to host it (Visual Studio Online). When I saw frustrations about not everyone being on the same page about what work was being done when, I pushed for tracking our work through work items in VSOnline. When we had issues with nightly jobs maxing out our RAM in the physical server box from Rackspace, I successfully proposed we move the applications to Azure Web Apps that we could scale up and down as needed.
By way of intuition I was gathering the pieces, but I didn’t know what puzzle I was putting together.
Opening the Box and Finding The Puzzle Pieces
For every pain point I personally felt as a developer, I advocated and pushed for a solution. What I was missing was the complete picture on the box of what DevOps was, what it meant, and how the various pieces were put together. One huge regret I had was recognizing that the people were the first step in this process. Without articulating the overall vision for what DevOps could achieve, every decision was piecemeal, and every decision required a new discussion to gather buy-in from stakeholders to make it work.
In the organizations I’ve seen over the years, this scenario is very common. Developers are focused on making new features, managers are focused on developing business value, and operations is focused on keeping everything alive. Since the process of collaboration and cooperation between these roles is left to chance, it’s often full of friction.
DevOps is a culture. It starts with the people. Often, it just starts with one person and spreads like wildfire when the small successes start to add up to big successes.
Puzzles Are More Fun Together
If you want help putting the pieces together, that’s where Nebbia can help. One easy way to get started is our DevOps Assessment. We come in, help you identify the state of your puzzle and what pieces you might be missing, and even can help you put a piece or two in, like creating a sample pipeline in Azure Pipelines.
Starting With The Sides Of A Puzzle
In life and in DevOps, starting with the middle of the puzzle is insanity. If you look at DevOps as a top-down initiative to be achieved with an iron fist, it can look like handing out random pieces of the puzzle one by one. “First we must do CI/CD pipelines, then we must do automated testing, then we must do…”
We must do none of those things. We may choose, instead, to foster a culture where collaboration is king and we’re working together to deliver value. One of the easiest ways to focus attention on a common set of values is to start measuring things. Humans have an innate drive to improve metrics. Want proof? Come play a board game with my wife. She will get very upset if she doesn’t win. Although the points in Yahtzee literally mean nothing, we can get very passionate and work very hard to improve our numbers.
If you aren’t careful about what is measured, it can lead to disaster. I recently read about an initiative in China where average drivers can use their dashcams to capture traffic violations, and then send the footage in and get a financial reward. On the surface, this is a great idea! Now everyone will be more careful in how they drive just in case someone catches them on camera, right? Wrong! Now some drivers with dashcams are driving erratically to spur other drivers to react, catching those other drivers doing illegal maneuvers, and then collecting the reward when they capture it on tape. Be very careful about what you measure.
In the book Accelerate, four measures are shown to have a strong correlation with organizational success:
- Lead Time: time from a customer making a request to the request being satisfied.
- Deployment Frequency: how often do things get into production, per developer.
- Mean Time to Restore (MTTR): how long it takes to recover from a system outage or failure.
- Change Fail Percentage: how often a change introduces a bug, fails to fix the problem, causes an outage, or fails to deploy.
I view these as sides of a puzzle. If a puzzle piece doesn’t fit within these four measures, at least until you complete the puzzle, it can probably be ignored for now.
Filling in the Pieces
Once you know the boundaries, you can start filling in the puzzle. Handily, the pieces link up to each other. There’s often a natural order of things as you start to put the picture together. For example, if you don’t know how to measure Mean Time To Restore yet, maybe it’s time to put some monitoring uptime. Once you see how long it takes to restore, you can start to get to root causes when it fails – which means putting in something like Azure Application Insights to gather data about why it fails. Once you start to get a picture of why it fails, you can start fixing low-hanging fruit. If you find that delivering fixes takes a while once you know what to fix, you can look at your CI/CD pipeline or change request process. It all feeds into each other, and as you add puzzle pieces you start to get a fuller picture of how they all fit together.
Completing The Puzzle
Aha! This is where the metaphor finally breaks down. The puzzle is never complete. You will always be finding new ways to improve how you bring value to your customers and clients. At Nebbia Technology, we are very free with sharing information on how to add more pieces because we truly want you to be successful. I get out of the bed in the morning because I want to make a difference in how people work and see them be wildly successful. Also, putting together the puzzle is fun – each piece you slot in completes the picture a little more and makes your life a little less hectic. If you feel busy but not necessarily productive in doing software development, we can help with that. It’s kind of our deal because we derive some serious joy from seeing the lightbulbs turn on when the pieces start to form a picture.