After watching this video, you will be able to explain the importance of measuring what
you want to improve, identify the value of social and DevOps metrics,
and recognize that DevOps changes your approach to problem resolution.
How do you change a culture?
This is from a paper by Steven Kerr from the Academy Management Journal back in 1975 on
“The folly of rewarding for A, while hoping for B.”
“Whether dealing with monkeys, rats, or human beings, it is hardly controversial to
state that most organisms seek information concerning what activities are rewarded, and
then seek to do (or at least pretend to do) those things, often to the virtual exclusion
of activities not rewarded.
The extent to which this occurs, of course, will depend on the perceived attractiveness
of the reward offered, but neither operant nor expectancy theorists would quarrel with
the essence of this notion.”
You cannot measure for A and hope you get B. It’s not going to happen because you
get what you measure.
So, measure what matters.
If you measure widget production, you will get lots of widgets.
If you measure lines of code, you will get many lines of code.
Semicolons all the way down.
We used to measure lines of code by the thousands of lines of code (KLOC).
Is it good code?
I do not know; I do not care.
I am measured by how many lines of code I write, so I am going to write verbose code.
Remember, you get what you measure.
If you measure people by ranking them against each other, you will get antisocial behavior.
A lot of companies do this—they rank people.
So, let me get this straight.
You want me to help my peer, but you are going to rank us against each other?
So, I help them so that they get a better ranking than me, then they get the pay raise
or the promotion that I want?
Yeah, how does that work?
Companies do this all the time, and their management doesn’t seem to get it.
You get what you measure.
If you want people to be social, then you must measure them on being social.
You should measure developers by their social interactions and sharing of code and knowledge.
That is how you get social coders.
Here are two metrics that I like to use to measure social coders.
Who is leveraging the code you are building?
Are you building code that the rest of the company or open-source community find valuable
enough to reuse in their solutions?
But that’s only half of the puzzle.
That will get people thinking about how can they make their code valuable to others.
But you need the second metric.
Whose code are you leveraging?
Are you wasting all of my development dollars reinventing wheels or are you leveraging the
existing wheels and only building the bespoke parts that don’t exist?
Both of these metrics are needed because they incentivize both sides to share their code
and reuse each other’s code because… you get what you measure.
You need a social metric to get social behavior.
DevOps is all about continuous improvement.
That means that you must know where you are coming from in order to measure if you are
going in the right direction.
It starts with taking a baseline.
What do you want to improve?
Maybe it currently requires six team members 10 hours to deploy a release of your product.
Maybe it costs X dollars for every release.
Whatever that measurement is, that’s the baseline.
Then you need to create a goal.
Metric goals allow you to reason about these numbers and judge the success of your progress.
Perhaps you want to reduce deployment time from 10 hours to 2 hours.
That’s a very achievable goal.
Your baseline determines that it takes 10 hours, so you aim for a threshold of fivefold
improvement to 2 hours.
Or maybe you want to go from needing 6 team members to one team member.
Or maybe you want to reduce the number of defects found in production.
Whatever it is, choose a goal and work on one at a time.
Then you judge the success of your process.
Did you go from 10 hours to 2 hours?
No?
Try something different until you achieve this measurement.
Then you start working on the next goal.
DevOps changes the objective.
We used to measure mean time to failure where you tried to make sure the server never went
down.
That is old-school thinking.
We need to go from mean time to failure to mean time to recovery.
You anticipate that the server will go down.
Just be sure you can recover quickly.
If your applications are built as a collection of microservices deployed in containers as
multiple instances, you can recover quickly by bringing up a new container.
And your customer might never even know that the service went down because there was no
single point of failure.
Containers may be continuously going up and down, but if you can recover quickly by spinning
up a new container, who cares it went down?
The customer never noticed.
It’s a whole new way of thinking about availability.
In this video, you learned that you should measure and reward what you want to improve.
Measuring social metrics leads to improved socialization and measuring DevOps metrics
allows you to see progression toward goals.
DevOps changes the objective of problem resolution from failure prevention to failure recovery.