“Continuous Delivery is the ability to get changes of all types – including new features, configuration changes, bug fixes, and experiments – into production, or into the hands of the users, safely, and quickly in a sustainable way.”
— Jez Humble
The most important word in Jez’s description of Continuous Delivery is sustainable.
In my experience, many teams interpret this definition in the order it’s written:
- Make sure the code works
- Get code into production.
- Think about sustainability.
This often leads to short-term wins at the cost of long-term pain. The real starting point should be sustainability. Then can you build a system that withstands the test of time instead of burning out under quick fixes and shortcuts.
The Runner’s Analogy
Think of Continuous Delivery like becoming a runner:
- You don’t just run fast on day one.
- You train, build a routine, and commit to a healthy lifestyle.
- At first, progress feels slow — but with discipline, you run farther and faster.
The same applies to software delivery: prioritize sustainable practices first, and speed will follow.
A Reframed Definition
If I were to rewrite Jez’s quote to reflect the right order of importance, it would look like this:
“Continuous Delivery is the ability to deliver code into production in a sustainable, safe, and fast way — enabling changes of all types, including features, configuration changes, bug fixes, and experiments.”
By flipping the order of priorities, you ensure that sustainability is the foundation, not an afterthought.