When I was working out the questions with Kia for his interview, he gave me a couple of suggestions for things he really wanted to talk about. As anyone who follows the series knows, I work out a list of questions the interviewee wants to discuss or answer (and maybe have never been asked before). We start by identifying themes (usually) and then flesh those into topics.
That’s my major goal in these: find out what thought leaders would like to talk about and then optimize the questions to get to that. It’s not journalism. It’s education.
Kia brought up . . . Dilbert. I said Kia had a sense of humor, right?
Kia Behnia: So, first of all, I will say that probably my most famous run in with celebrity did not happen in technology, but my first job out of college was to work at Pacific Bell, where Scott Adams founded Dilbert and I worked in fact one-floor above him in ISDN labs. And so for the first couple of years at the Dilbert cartoon, I literally knew all the people that he was writing about.
One of the things that, you know, Dilbert has always for many us exemplified is: bad management ideas gone awry. There is story, a true story, that I would say really exemplified the problem around what DevOps is trying to deliver. I recalled we had an engineering team that was developing and building new features and functions and the quality of this product was not really where it needed to be.
So, one of the leaders in quality put out a bounty program that said look for all our QA engineers went to find the bug, we will give you a reward. And sure enough what ended up happening is that instead of our quality matrix going down, all of a sudden people were finding more bugs, because they were really beating up the product.
And the engineering leaders, the head of engineering came in and said, “Well, my guys are working really hard. They’re working overtime to keep up with fixing these bugs. I want to have a reward system, so that I can pay them to actually close out these bugs and get the matrix back down.”
So, of course, what happened was you would find in software buttons that were deliberately put in there, that said “click me”, and the product would crash and you know, the quality matrix went to hell. We were spending a lot of money fixing bugs in the products.
I use that as an example of, you know, if you actually don’t sit down and think about what kind of behavior you want to setup and think about your processes.
What ends up happening is “random acts of DevOps”. And this is what I have seen, which is you take some of the basic principles, you read the Wikipedia site, some of the key presentations of movement. You distribute it to the various orgs and you don’t have a dialog that says, “What and how are we going to change our processes?” So that as we’re incentivizing people being better at releasing new code, we actually don’t create another problem whether that is in operation or the QA area.
[…] I think there is something to be said for having very clear objectives to drive through. And that’s why, you know, the kind of the discussion around DevOps by itself is not as interesting as when they got applied to a particular vertical or particular project, where you can actually say, “What are my business goals? Are my business goals to increase the rate at which I’m deploying a particular product set or is it to improve quality, consistency, reliability, cost of delivery.”
Yes, and once you have those business benefits it’s easier to go back and say, “Therefore, these steps, these specific set of actions are more important for us.”