Amazon (hardback, kindle)

InformIT (pdf, epub, mobi)

中文 (in Chinese)
日本語 (in Japanese)
한국말 (in Korean)

You can also see a list of all my publications and talks, including slides, on the Publications page.

Upcoming talks


jez_new_largeJez Humble is a vice president at Chef, and co-author of the Jolt Award winning Continuous Delivery, published in Martin Fowler’s Signature Series (Addison Wesley, 2010), and the forthcoming Lean Enterprise, in Eric Ries’ Lean series. He has been fascinated by computers and electronics since getting his first ZX Spectrum aged 11, and spent several years hacking on Acorn machines in 6502 and ARM assembler and BASIC until he was old enough to get a proper job. He got into IT in 2000, just in time for the dot com bust. Since then he has worked as a developer, system administrator, trainer, consultant, manager, and speaker. He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services and on-line retail companies. From 2004 – 2014 he worked for ThoughtWorks and ThoughtWorks Studios in Beijing, Bangalore, London and San Francisco. He holds a BA in Physics and Philosophy from Oxford University and an MMus in Ethnomusicology from the School of Oriental and African Studies, University of London. He is presently working for Chef and living in the San Francisco Bay Area with his wife and daughters.

Dave Farley has been having fun with computers for nearly 30 years. Over that period he has worked on most types of software, from firmware, through tinkering with operating systems and device drivers, to writing games, and commercial applications of all shapes and sizes. He started working in large scale distributed systems about 20 years ago, doing research into the development of loose-coupled, message-based systems – a forerunner of SOA. He has a wide range of experience leading the development of complex software in teams, both large and small, in the UK and USA. Dave was an early adopter of agile development techniques, employing iterative development, continuous integration and significant levels of automated testing on commercial projects from the early 1990s. He honed his approach to agile development in his four and a half year stint at ThoughtWorks where he was a technical principal working on some of their biggest and most challenging projects. Dave is currently working for the London Multi-Asset Exchange (LMAX), an organization that is building one of the highest performance financial exchanges in the world, where they rely upon all of the major techniques described in this book.

  • Pingback: Agile software, continuous delivery and passionate users « WatirMelon

  • Pingback: Agile 2011 – Applying the Lean Startup Model to the Enterprise

  • Pingback: Facebook and the perpetual beta | Amanda Belton

  • Pingback: ThoughtWorks’ Martin Fowler & Jez Humble in Berlin

  • Pingback: Go Agile! | Hecate's Muse

  • Pingback: DevOps Rock Star dinner |

  • Pingback: DevOps Rock Star dinner |

  • Pingback: 3000 Downloads & Counting: IT Manager’s Guide to Continuous Delivery : XebiaLabs

  • Tim Robinson

    I’m really enjoying the Continuous delivery book but I’m concerned about some inconsistency. In chapter 10 p268 you recommend users should be upgraded to new versions of your application by default (that’s the whole ethos of continuous delivery), yet in chapter 13 (p369) when discussing dependencies, you say “Don’t blindly take updates to third-party libraries”. In essence you’re saying that you expect your customers to trust you to deliver updates automatically but you shouldn’t trust your suppliers to deliver automatic updates to you. Isn’t this a bit hypocritical?

    • Bas Meijer

      No, it’s not hypocritical, “Everyone is involved”. Test every update to third-party libraries in your own pipeline, and report regressions to suppliers. Use a “guarded” trigger to pin the version when these builds fail, but make them “fluid” again once the issue is fixed.

    • Jez Humble

      Hi Tim. The inconsistency is resolved once you realize that in the first example we’re discussing user-installed software, and in the second example we’re talking about an input to the deployment pipeline. The context is different.

      I expect customers to trust me to deliver updates _that I have tested_. We also say (on p269) that there should be an option to turn off automatic updates for users who are more risk averse (such as corporate environments). If I trust the suppliers of a particular third-party library, I will use a “fluid” dependency. If I don’t, I will use a “guarded” or “static” dependency, as Bas says. It all comes back to two issues – trusting, and testing.

      Finally, I am going to turn off comments on this page – it’s not really the right place to be discussing technical issues. I recommend subscribing to the continuous delivery mailing list on Google Groups instead.