Application of the Scientific Method to Software
Many people see continuous delivery as "solving the last mile problem"; that is, making it possible to get to production frequently. That's certainly an important part of it. But the picture is even bigger than that! At its core, continuous delivery is really about application of market discipline to software delivery efforts. The critical questionsWill this release increase productivity? Will this change increase the number of flights that people book?are answered only by putting the software into production and seeing the results (see Figure 1). Until you're in production, you don't know whether it really works!
So why continuous delivery? Why doesn't any kind of delivery provide this market discipline? Suppose you have an eCommerce website on a quarterly release cycle. On each release, you put forth 10-20 new features to production. Immediately, sales go down (or, for that matter, perhaps they go up). How do you know what particular change to the software caused the financial loss (or benefit) in production? The less continuous the delivery, the more you're changing on each release. The more you change on each release, the less likely that you'll know precisely what you did that hurt or helped the site. Put simply, the less frequently you deliver, the less visibility you have into what actually works!
When you think about it, the concept of continuous delivery isn't really new. Creating a hypothesis, developing the hypothesis, testing it, and controlling for other variables by isolating the one that changesthat is, the scientific methodisn't exactly controversial. While Agile certainly has made strides, putting a greater emphasis on making sure that testability is a first-order concern in software delivery work, continuous delivery closes the loop. It moves us from "It should work, according to our tests," to "It did work, according to our users."