At QCon London 2015, Dave Farley proposed that although the state of software development has been suboptimal in the past, studies are revealing that the implementation of continuous delivery leads to considerable improvement. Farley stated that continuous delivery changes the economies of software development, and provides more rapid business idea validation, reduced defect rates and improved service restoration times when a failure does occur.
Farley opened the talk by discussing that the state of software development has been suboptimal in the past, and quoted a series of reports by KPMG, Logica and the McKinsey report with statistics to quantity the statement. The software industry has attempted to improve development methodologies over the past twenty years, including a move from sequential approaches such as Waterfall towards more iterative processes like Scrum, however Farley proposed that we have failed to learn from fundamental mistakes.
The primary purpose of software delivery is to provide a product to the customer that will validate a business idea, and ultimately provide value to the end-user. There must be feedback between the customer and the business, and this iterative process must be performed quickly, cheaply and reliably.
Farley proposed that the greatest invention by man is science and the scientific method. This method is the key to implementing a fast feedback loop in software delivery. Farley stated that the basic steps of the scientific method include problem characterisation, hypothesis generation, deduction and experimentation.
Characterisation - Make a guess based on experience and observation.
Hypothesis - Propose an explanation.
Deduction - Make a prediction from the hypothesis.
Experiment - Test the prediction.
Repeat!
Farley continued by stating that principles from lean thinking, such as ‘build quality in’, ‘optimise the whole’ and ‘amplify learning’ can dramatically reduce software delivery cycle time. Farley provided an example from a typical traditional software development methodology, which had a cycle time of 103 days, and compared this to a lean continuous delivery methodology, which had a cycle time of 57 minutes. A short cycle time alters the economics of software delivery by allowing ideas to be validated rapidly. If any defects are introduced to the system, then a fast cycle time enables a small mean-time-to-recovery (MTTR), as software modifications can be reasoned about more easily over the shorter period of time.
Farley underlined the importance of continuous delivery by quoting the first principle of the Manifesto for Agile Software Development “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, and proposed a series statements to fully define the concept of continuous delivery:
The first principle of the agile manifesto.
The logical extension of continuous integration.
A holistic approach to development.
Every commit creates a release candidate.
Finished means released into production!
Farley stated that the core principles of continuous delivery include creating a repeatable and reliable process for releasing software, automating almost everything, keeping everything under version control, building quality in, re-defining ‘done’ to mean released, making everybody responsible for the release process, and implementing continuous improvement.
The core principles should be included into the implementation of a deployment pipeline, the purpose of which is to take code committed by a developer to the point where the modification is providing value to a customer, detecting and preventing any changes that will lead to problems in production. A deployment pipeline should enable collaboration between the various groups involved in delivering software and provide everyone visibility about the flow of changes in the system.
Farley stated that a series of incorrect arguments are often made against implementing continuous delivery within an organisation. The first argument, “this may work for small projects but can’t possibly scale”, can be rebutted by examining the Google build process. Google predominantly utilise a single monolithic code repository, and run continuous build and test on each commit for 60 million builds per year and 100 million lines of code. Farley stated that all tests are run on every commit, and 100 million test cases are executed per day.
The second argument discussed, “this is too risky, releasing all the time is a recipe for disaster”, was countered by reviewing the Amazon build process. Farley stated that the implementation of continuous delivery at Amazon resulted in a 75% reduction in outages triggered by deployment between 2006 and 2011, and a 90% reduction in outage minutes triggered by deployment.
The final argument against implementing continuous delivery was stated as “this may work for simple websites, but my technology is too complex”. Farley rebutted this argument with the story of HP’s transformation of the development approach for all HP LaserJet Firmware products, which was a large complex hardware-based project with multiple products and a four-year timeframe. The result of the implementation of continuous delivery was a 10x increase in developer productivity.
Farley concluded the talk by stating the positive effects that implementing continuous delivery has on a business, and proposed that continuous delivery changes the economics of software delivery. Farley quoted the Enterprise Management Associates (EMA) ‘DevOps and Continuous Delivery’ report 2014, stating that 87% of companies with development and operations functions that were rated as “excellent” saw revenue growth greater than 10% in 2013 and in contrast, only 13% of companies with development and operations functions that were rated “average” or worse saw similar growth.
Farley quoted Puppet Labs ‘2014 State of DevOps Report’, stating that the effect of continuous delivery lead to higher throughput, higher reliability and a twelve times faster service restoration time when a failure did occur. Quoting the Puppet Labs report again, Farley stated that organisational culture is one of the strongest predictors of both IT performance and overall performance of the organisation:
We can now assert with confidence that high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share.
The slides for Dave Farley’s talk “The Rationale for Continuous Delivery (The culture and practice of good software development)” can be found on the QCon London 2015 website schedule page.