May 13, 2021

A Pioneer of Continuous Delivery, Jez Humble, Explains Customer Focus

DevOps
Infrastructure Automation

By

As a pioneering author and thinker in the discipline of continuous delivery, Jez Humble has made a career out of starting conversations around the best way to deliver software with automation. We interviewed him ahead of his Puppetconf keynote to find out why continuous delivery matters and how a DevOps mindset can help organizations achieve it.

This article was originally written from a 2013 conversation with Continuous Delivery author Jez Humble. Elements of the conversation, including quotes, have been edited for readability and clarity.

Table of Contents

Who is Jez Humble?

Jez Humble is an author, developer, teacher, and DevOps thought leader. He is best known as the author of several award-winning books on the theory and practice of DevOps.

In addition to authoring "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation," which is known as a definitive source of thought leadership in continuous delivery, Jez Humble is also known as the author of "The DevOps Handbook" and "Lean Enterprise: How High Performance Organizations Innovate at Scale."

If your technical team is talking about and working towards continuous delivery, you should tip your hat to Jez Humble. Jez is one of the leading thinkers driving big changes in software development.

In addition to being a pioneering thinker around continuous delivery, Jez Humble also contributes thought leadership around DevOps, a term he thanks Patrick Debois for inventing. Commonly described as a cultural movement, “DevOps is much of the ‘how’ of achieving continuous delivery,” Jez said.

Continuous Delivery, Jez Humble Says, Helps Everyone

Continuous delivery offers great benefits to both business and technical people within an organization. The core concept of making small frequent changes, and testing at every step, reduces the risk inherent in deploying new code. From the business point of view, continuous delivery allows a company to discover more quickly just how well a new product or feature will work.

🛠️ Tools: Discover Continuous Delivery for Puppet

“When a C-level person approves a project and analysts come up with a big list of requirements, these aren’t really requirements – they are guesses, or hypotheses,” Jez said. No one really knows yet if the product will actually address the needs of its target customers, whether internal or external. “That’s where continuous delivery comes in; it makes it more economical for you to run lots and lots of experiments.”

How Continuous Delivery Makes Agile Better

In describing the use of continuous delivery, Jez said it goes hand in hand with Agile, the method of developing software in small increments. Agile was a reaction to the waterfall method of developing software, the long-term de facto standard. Developers working the waterfall way write lots of code over longer periods before testing.

While this method seems to make intuitive sense – you need to build a fairly complete system before testing – there are known pitfalls. A big one: When the completed code is “tossed over the wall” – that is, passed on to IT operations for deployment – it usually doesn’t meet the needs of operations.

“It’s hard to monitor, there’s no facility for archiving data, the log messages are useless, and it’s not designed to degrade gracefully under high load or unexpected failures,” Jez explained.

With continuous delivery, you create, test and deploy code in much smaller increments, making it easier to identify which changes break the system. “You get quality because you test more often, and catch bugs when they’re small and cheap to fix,” Jez explained. The result: better, more consistent code quality.

Developers also find continuous delivery a more satisfying framework. “They’re motivated because they get done with stuff, and they get feedback,” Jez said. It adds up to less frustration for developers, and more of their time freed up to be creative.

Continuous Delivery Requires a Shift in Attitudes, According to Jez Humble

While continuous delivery sounds like a dream come true, there can be pushback from developers who believe the hand-crafted, unique solution is always best.

“Developers can have a bias – you want your solution to be perfect,” Jez said. But it makes a lot more sense to make sure whatever you’re building is valuable before putting a lot of time and effort – expensive time and effort – into building a perfectly crafted, fully featured solution.

Developers who are used to creating more code over longer cycles may also not know how to work in small increments. “The trick is to do the smallest possible amount of work to create the experiment that produces meaningful data,” Jez said. “Even if you’re not releasing frequently, you still have to behave as if it's valuable to work in increments, and as you write code, create tests that will ensure you don’t create regressions as you move forward.”

What We Talk About When We Talk About DevOps

The increasing adoption of continuous delivery is really driven by the movement of so many products, services and business models to the web. That also explains why DevOps has become so important over the last few years, Jez said.

“Part of the work of operations is to provide developers the tools they need to validate whether the changes they’re pushing are safe,” a concern that’s even more important when your code is available to any and all on the web, at all hours of the day or night.

Without a culture that emphasizes active collaboration between dev and ops, continuous delivery becomes very difficult, if not impossible. You can’t toss frequent, incremental changes over a wall; in fact, IT ops people should be included early in the software design process to make sure their needs are considered.

“Developers need to treat operations as customers of the systems they build,” Jez emphasizes. After all, it’s IT’s job to maintain these systems for the good of the entire organization.

While culture change is not simple, the transition can be eased considerably by keeping in mind that the goal of DevOps is the same as it always has been for people who care about quality code, Jez said. “To quote Damon Edwards, it’s about creating measurable customer outcomes.”

TRY PUPPET FOR FREE

This blog was originally published on July 9, 2013 and has since been updated for relevance and accuracy.

Learn More

Aliza Earnshaw

Aliza Earnshaw

Aliza Earnshaw started writing about technology as a freelancer during the dot-com and telecom boom. She joined the Portland Business Journal as its technology reporter just as the dot-com boom was becoming the dot-com bust. Aliza's appetite for tech startups led her to join one in 2009. She started working at Puppet in 2013, writing customer stories and editing whatever she can get her hands on.