James Turnbull speaks regularly at conferences including OSCON, Linux.conf.au, FOSDEM, OpenSourceBridge, DevOpsDays and a number of others. He is a past president of Linux Australia. He’s an accomplished IT Jedi master, Puppet master and a valued contributor to the DevOps community.
James and I worked out questions to ask and he was pretty much open to anything I pitched, so a couple I had some fun with (viz question about risks with open source). I then pitched the agreed-upon list over to the BMC podcast person and they recorded an interview.
As with previous interviews, I went through the transcript of the podcast with James and extracted excerpts. I choose excerpts for insights or other qualities that I like.
And once again, folks, these headers and the excerpts are done by me and, if you don’t like them, it’s my fault I go for punchy titles and I try to go for quotable content.
Note that I also edit the transcripts mildly to improve them in ways that I don’t think effect content. We all have verbal tics and habits that don’t usually transcribe well, you know?
James Turnbull: So I think there are a few examples of this but the classic scenario that I usually cite to people when they ask about the brokenness, is application deployment. A classic application deployment scenario is there’s a project within a business unit and they develop an application and that application is generally developed sort of in isolation and it has some business requirements and some functional requirements and a timeframe and a project plan.
And it gets developed and then maybe it’s tested in a test environment, create a staging environment, the developers go home on a Friday night and the operations team take over. They’re trying to deploy the actual application into production. And it all goes wrong.
Because you don’t know if the application was even architected to consider what’s in production. It wasn’t tested in an environment that looks like production. It’s using a set of libraries that aren’t running in production and a number of different reasons. You know it doesn’t map to the network topography, you can’t back it up, it doesn’t meet the security requirements.
And the first thing those operations guys do is say, the application development team have created this disastrous product and it’s all gone wrong and it turns into this massive blame storm.
So, from my perspective, that’s not fun experience to work in. You know I’ve been in those environments. I’ve sat in those post mortems where you have to drag application development into those post mortems. And they’re usually reluctant to be there.
And it’s mostly about finding out who’s fault it is.
And no one wants to work like that.
I think we have to learn how to, how to change that methodology. Because first and foremost, from my perspective, it makes people happier if you work in a happy environment and it’s collaboration and it’s about delivering services to the business. You know that’s an environment I actually want to work in, rather than one where you know I’m up at 3 o’clock in the morning, full of coffee and aggravation.
My second excerpt from James’ interview is coming up. It’s on Tribal Mismatches and Change.