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:

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

For fellow developers worried that "Lean" is just a buzzword, I've got two books to recommend:

"Lean Software Development" by Mary Poppendieck. Talks about what Lean Manufacturing principles look like when applied to software development: http://www.amazon.com/dp/0321150783

"Toyota Kata" by Mike Rother. Nominally about Toyota's personnel management. Actually about the philosophy behind Lean, and how most American companies trying Lean are missing the deeper point. http://www.amazon.com/dp/0071635238

To me, Lean is what you get when engineers think sufficiently hard about the nature of business. It is deeply different than the MBA dogma that passes for business thinking in the US.