Another week, another false dichotomy article on HN.
If there's an inverse correlation between the speed of deployment and the quality of your software, you're doing it wrong.
The Continuous Delivery philosophy is borrowed from Lean Manufacturing, and a fundamental tenet of that movement is "Build Quality In." In fact Lean is nearly synonymous with TQM, or Total Quality Management. If you've separated the two, then you've missed the entire point.
This tenet is carried over into the software world by Martin Fowler in his book Continuous Delivery, as well as all of the major advocates of lean software processes, for instance David Anderson and the Poppendiecks in their highly influential series of books on Lean Software.
Essential to a successful continuous deployment process is unit testing, continuous integration and built-in testing processes all along the way to feature deployment. These should be focused on quality all along the way: that's the point of continuous deployment, to allow for focused feature development that is highly tested and can be released with higher confidence than the old method of multiple feature release, which are heavy, harder to test and have more integration concerns.
The point of fast releases should never be to allow for "shitty software," but rather to deliver features that users can enjoy as soon as possible, create a process where deployments become highly automated, low-risk events, and gather feedback early and often on the experience of users with finished polished features so that effective product evaluation is happening constantly and the company can adapt quicker to new data and new trends.
A quick perusal of even the first chapter of any of the major volumes on Continuous Delivery should clear this up:
And there's a fantastic presentation by David Anderson on Kanban on InfoQ, which nicely illustrates why quality is one of the major reasons you should consider a rapid release process like Kanban:
I thought the continuous delivery book was written by Jez Humble and David Farley. Fowler provides a foreword for it http://www.amazon.com/gp/product/0321601912?tag=contindelive.... Other than that I totally agree with you comments - Lean Continuous and Agile are not orthogonal to Quality.
You're right, sorry. It's in the "Martin Fowler" Addison Wesley series of books, it's not written by Fowler. I've had the book on my shelf and read a good bit of it, and should have caught that!
"Martin Fowler" is on the cover in two different places, plus it looks just like the cover of Patterns of Enterprise Application Architecture, which he did write, so I've had that misconception in my brain for a while. Failure to test assumptions...
Offhand I can think of a few: ThoughtWorks uses it on most of their projects afaik. Github I believe does as well. They published an interesting blog on their deployment process a couple of months ago.
Where I work at LivingSocial the web application is deployed daily, sometimes dozens of times a day. I've recently taken over the Android project's infrastructure and we're in the process of implementing Continuous Delivery for that app as well.
David Anderson gives examples of implementing it at both Microsoft and Corbis, Bill Gates' other software company.
Some good points, but (there's always a "but" :-) as with most of these, let's call them modern processes (maybe not even that modern if you consider what the likes of Peter DeGrace were saying back in 1990), continuous delivery forces an engineering paradigm onto the (often unwilling) user.
What does the constant barrage of (for example) iTunes or Flash updates do to the user's perception of quality?
What is the impact of the Chrome release cycle on a corporate environment that needs to test each revision on a model office, in case there's an impact on one business-critical application or other?
Yeah this is a good point, and that's a balance I'm actually in the process of determining for my current project.
User expectations are different for mobile apps -- anecdotally it seems users not as annoyed by mobile app updates as they would be for Flash or even Word, because the process is a lot lighter and less painful. For web applications it's transparent to the end user.
But, yes for rich client apps it's a concern. I think the trick is to deliver features rather than bug fixes and shape user expectations towards getting something new from an update rather than getting nothing but fixes that should have been in place to begin with.
If there's an inverse correlation between the speed of deployment and the quality of your software, you're doing it wrong.
The Continuous Delivery philosophy is borrowed from Lean Manufacturing, and a fundamental tenet of that movement is "Build Quality In." In fact Lean is nearly synonymous with TQM, or Total Quality Management. If you've separated the two, then you've missed the entire point.
This tenet is carried over into the software world by Martin Fowler in his book Continuous Delivery, as well as all of the major advocates of lean software processes, for instance David Anderson and the Poppendiecks in their highly influential series of books on Lean Software.
Essential to a successful continuous deployment process is unit testing, continuous integration and built-in testing processes all along the way to feature deployment. These should be focused on quality all along the way: that's the point of continuous deployment, to allow for focused feature development that is highly tested and can be released with higher confidence than the old method of multiple feature release, which are heavy, harder to test and have more integration concerns.
The point of fast releases should never be to allow for "shitty software," but rather to deliver features that users can enjoy as soon as possible, create a process where deployments become highly automated, low-risk events, and gather feedback early and often on the experience of users with finished polished features so that effective product evaluation is happening constantly and the company can adapt quicker to new data and new trends.
A quick perusal of even the first chapter of any of the major volumes on Continuous Delivery should clear this up:
http://martinfowler.com/snips/201006021426.html http://www.amazon.com/Lean-Software-Development-Agile-Toolki...
http://www.amazon.com/Implementing-Lean-Software-Development...
And there's a fantastic presentation by David Anderson on Kanban on InfoQ, which nicely illustrates why quality is one of the major reasons you should consider a rapid release process like Kanban:
http://www.infoq.com/presentations/kanban-for-software