Share: |


Jez Humble banner.jpg

 

Today it’s my pleasure to present the first part of an interview with Jez Humble.

 

Jez is a well-known name in IT circles. He's multi-talented individual, author of CONTINUOUS DELIVERY, partner at ThoughtWorks Studios, blogger at continuousdelivery.com, and generally knowledgeable guy who also has deep roots in DevOps.


 

http://m4.licdn.com/media/p/3/000/00d/156/35a48f8.jpg

Jez and I conducted via email over a few week period of time, I'd send a question or two at a time, getting a reply back. This started a couple of months ago.

 

There is no podcast version as Jez wanted to do Q&A via email relay.

 

So, I’ve edited out the non-essential, non-Jez portions – basically my end of the conversation -- as much as possible for your reading pleasure.

 

_____________

 

 

 

 

Chris: Let's start the interview with a bit of your background -- and what brought you to thinking about DevOps and DevOps practices and culture?


 

Jez: I got into computers as a teenager, in the days when you really had to understand the internals of computers to get much done. The home computers I owned as a teenager - a ZX Spectrum, a BBC Master and an Acorn A3000 (one of the first machines with an ARM) were simple enough that you could reasonably expect to understand what every memory location was for, how to talk to the various I/O chips, and how to use networking primitives, for example.

 

 

After college, when I had to do real work, I fell into computers because it was the height of the dot-com boom and that's what everybody else was doing. I was the second technical hire at a start-up and ended up doing a bit of everything: systems administration, network administration, support, infrastructure, and development.

 

 

In fact, we were doing continuous deployment back in 2000 - we used to ftp files from our workstations directly into production (obviously not something I'd advise today). So when I encountered the devops movement it felt like a natural extension to how I was already doing things - which is not to deny the many innovative advances that people in the movement have made.


 

Dave and I were writing the Continuous Delivery book as the movement emerged, and of course many of the ideas discussed in the early days of devops fitted neatly with the message of the book, so we were able to incorporate some of them quite near to the publisher's deadline without changing very much.


 

Chris:  What is DevOps and what is it not?

 

 

Jez: I think all of us are still trying to answer that question, which is a good thing. The term "devops" is essentially a placeholder for a continuing discussion about how everyone involved can work together to improve the business of building and running systems.

 

 

DevOps extends right past engineering into requirements management and back to your customers (which is also where you end up if you keep going in the other direction). It's a mistake to think of devops as a linear thing - you need to think of it as a cycle which starts and ends with your customers, where changes are the inventory that moves through the cycle.

 

 

 

Every team and every organization needs to have that discussion, and the outcome of the discussion will be different for each of them. Indeed, it will only be a starting point, because we are always evolving better ways to do this through experimentation. So I think that a desire to do better tomorrow than you did today, and a belief that each of us has the power to do better, is really at the heart of devops.

 

 

That sounds very kumbayah, but if each of us did something every day to make things a little bit better - simplified and automated some step in a manual provisioning process, put some time in to make the automated tests less flaky, or went to have lunch with one of the DBAs - lasting, significant change is achieved through the accumulation of these things.

 

Chris: What is the role of automation in DevOps?

 

 

Jez: Clearly, one of the biggest sources of inefficiency and things going wrong is manual processes. There's no excuse for not working to automate your build, regression tests, and deployment process in this day and age.


 

Of course it's much, much easier if you're starting greenfield than if you have a gnarly, complex system comprised of thousands of individual bits of software. The key there is to simplify as you automate, and to be incremental. Simplifying things is hard, because part of simplifying things is factoring out duplication, and you need to go and have conversations with other people to work out how to do that.

 

 

The other big problem is that simplification and automation can't just be reactive - we have to design our systems with testability, automation and resilience in mind. These represent constraints on architecture, and if you have a system that isn't designed with these things in mind, part of your work is going to be changing the architecture of your system (over time) to make it more amenable to these kinds of techniques.


 

And of course re-architecture, because of Conway's Law, needs to consider your organizational structure, not just the topology and configuration of your systems. Thus automation in these kinds of scenarios is a wicked problem. That's why it's important to proceed iteratively and incrementally through a process of controlled experimentation.


 

Chris: How far back into Dev does/should DevOps extend?


 

Jez: DevOps extends right past engineering into requirements management and back to your customers (which is also where you end up if you keep going in the other direction). It's a mistake to think of devops as a linear thing - you need to think of it as a cycle which starts and ends with your customers, where changes are the inventory that moves through the cycle.


 

Continuous delivery is about optimizing the cycletime so that everybody develops an intimate connection to their customers, and to the products of their work. This is essential whenever you're involved in a creative endeavor - one of the most inspiring things I've seen recently is a video by Bret Victor, who helped design the iPad and various other cool things. He says, "So much of creation is discovery, and you can’t discover anything if you can’t see what you’re doing."

 

_______________

 

 

That's the end of the first excerpt from Jez's interview. Part 2 on "DevOps Take-Aways" is coming up soon.