David Farley > Quotes

“The earlier you catch defects, the cheaper they are to fix.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Every change that is made to an application’s configuration, source code, environment, or data, triggers the creation of a new instance of the pipeline. One of the first steps in the pipeline is to create binaries and installers. The rest of the pipeline runs a series of tests on the binaries to prove that they can be released. Each test that the release candidate passes gives us more confidence that this particular combination of binary code, configuration information, environment, and data will work. If the release candidate passes all the tests, it can be released. The deployment pipeline has its foundations in the process of continuous integration and is in essence the principle of continuous integration taken to its logical conclusion. The aim of the deployment pipeline is threefold. First, it makes every part of the process of building, deploying, testing, and releasing software visible to everybody involved, aiding collaboration. Second, it improves feedback so that problems are identified, and so resolved, as early in the process as possible. Finally, it enables teams to deploy and release any version of their software to any environment at will through a fully automated process.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Indeed, there is a school of thought that any work on a branch is, in the lean sense, waste—inventory that is not being pulled into the finished product.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“In software, when something is painful, the way to reduce the pain is to do it more frequently, not less.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Asking experts to do boring and repetitive, and yet technically demanding tasks is the most certain way of ensuring human error that we can think of, short of sleep deprivation, or inebriation.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“There should be two tasks for a human being to perform to deploy software into a development, test, or production environment: to pick the version and environment and to press the “deploy” button.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Releasing software is too often an art; it should be an engineering discipline.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“Engineering is about adopting a scientific, rationalist approach to solving practical problems within economic constraints, but that doesn’t mean that such an approach is either theoretical or bureaucratic. Almost by definition, engineering is pragmatic.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“Context matters. I asked a friend whose code I admire, if he had any recommendations to demonstrate the importance of cohesion, and he recoomended the Sesame Street YouTube video `One of these things is not like another”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“To become experts at managing complexity, we need the following: Modularity Cohesion Separation of Concerns Abstraction Loose Coupling”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“If It Hurts, Do It More Frequently, and Bring the Pain Forward”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Figure 5.1 A simple value stream map for a product”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“The programming language that you choose, doesn't really matter. The framework that you employ, doesn't really matter. [...] in essence, the choice of one tech over another, has less impact on the outcome than how that technology is applied.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“In this school of tought, testing drove the development process and even more importantly, the design of the software itself. Software using TDD looked different from software that was written without, to make the software testable it was important to make sure that expectedd behaviours could be evaluated, this pused designs in aprticular directions.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“Throughput is the number of transactions a system can process in a given timespan. It”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“This principle is really a statement of our aim in writing this book: Releasing software should be easy. It should be easy because you have tested every single part of the release process hundreds of times before. It should be as simple as pressing a button. The repeatability and reliability derive from two principles: automate almost everything, and keep everything you need to build, deploy, test, and release your application in version control.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“The most important practice for continuous integration to work properly is frequent check-ins to trunk or mainline. You should be checking in your code at least a couple of times a day.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Software that was testable, was modular, was loosely coupled, exhibited high cohesion, had a good separation of concerns and implemented information hiding, these also happened to be properties that are widely regarded as markers of quality in software.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“Our proposal is not a technical solution but a practice: Always commit to trunk, and do it at least once a day. If this seems incompatible with making far-reaching changes to your code, then we humbly submit that perhaps you haven’t tried hard enough.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“It is essential for the smooth running of the delivery process to fly people back and forth periodically, so that each local group has personal contact with members from other groups.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Code is a communicatio tool, we should use it communicate, sure it needs to be machine readable and executable too, but that is not really it's primary goal, if it was we'd still be programming by flipping switches on the front of our computers or writing machine code. The primary goal of code is to communicate ideas to humans.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“aim is to make the delivery of software from the hands of developers into production a reliable, predictable, visible, and largely automated process with well-understood, quantifiable risks. Using the approach that we describe in this book, it is possible to go from having an idea to delivering working code that implements it into production in a matter of minutes or hours, while at the same time improving the quality of the software thus delivered. The vast majority of the cost associated with delivering successful software is incurred after the first release. This is the cost of support, maintenance, adding new features, and fixing defects. This is especially true of software delivered via iterative processes, where the first release contains the minimum amount of functionality providing value to the customer. Hence the title of this book, Continuous Delivery, which is taken from the first principle of the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“We write code to express ideas as clearly and simply as we can, at least that's how it should work. We should never choose brevity at the cost of obscurity.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“It is worth emphasizing that branching by feature is really the antithesis of continuous integration, and all of our advice on how to make it work is only about ensuring that the pain isn’t too horrible come merge time.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“One of the problems in ML, is that the people doing it often don't come from a software background, as a result, many of the techniques that have become normal for software development, even basic ones like version control, are not the norm.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“The systems that we build please their users more. We see dramatically fewer bugs in production, and teams that employ these ideas find it significantly easier to change almost any aspect of the systems that they work on as their learning evolves. The bottom-line result of this is usually greater commercial success for the organizations that practice in this way. These attributes are the hallmarks of engineering.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“Another important tool that helps us creating better systems, is separation of concerns [...] One class, one thing. One method or function, one thing.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster

“There are various incremental improvements to the way software is delivered which will yield immediate benefits, such as teaching developers to write production-ready software, running CI on production-like systems, and instituting cross-functional teams.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

“Making our code readable is, to my mind, both a professional duty of care, and one of the most important guiding principles in managing complexity, so I prefer to optimize to reduce thinking rather than to reduce typing.”
― David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster