Reasoning From First Principles
Heaven supports worthy aims
The first principle of the Agile Manifesto is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” It serves as a sort of North Star for our a software product journey. That principle is the inspiration to a technical practice that goes by the name of “Continuous Delivery” which we can talk about implementing.
Principles vs. Practices
It is no great bargain if you never get small things done because you’re too busy trying to do great things, forgoing the benefits of improvements that might be quickly implemented because you’re off slaying the dragon of some challenging technical practice. One should aspire to mastering difficult new practice areas, but not at the expense of being blinded to easy and straightforward alignments of our process to core principles of Agile and Lean.
Heaven supports worthy aims.
— Sancho Panza
Consider the distinction between principles and practices: you can reflect on a principle while implementing a practice is a hands-on activity. Principles are by nature lightweight and universal, whereas practices require substance and specificity.
Continuous Delivery
The canonical reference to the practice of Continuous Delivery is Jez Humble and David Farley’s book Continuous Delivery. CD practice is much more than just DevOps, and when you get into it, it is a very big undertaking for any organization. As much as I recommend it, you don’t have to build the whole CD practice to benefit from reflection on the principle.
Think of it this way: the Agile principle of Continuous Delivery is like contemplating the sunrise from a beach on Nantucket, reflecting on your problems and possible solutions. The technical practice of Continuous Delivery is like making a bike trip from Nantucket to Monterrey Bay, California; considerably more effort with tremendous potential for reward, but don’t discount the value of what you can learn without ever leaving the beach.
Reasoning vs. Reacting
Once when a high profile deployment failed, it drew the attention of managers who typically were not involved in releases. Before the problem could be diagnosed and fixed, the email chain of action and reaction grew to predictable confusion. Because the incident got a lot of extra attention, the post-mortem was tense.
It was clear that the problem could have been avoided with proper testing. A suggestion was made that we adopt TDD, a great practice, but hardly something that you can bring about from scratch without a significant commitment. There is tooling and workflow to consider, and important implications for how developers approach work. Unguided and over-enthusiastic developers rushing into TDD unprepared can leave the delivery schedule in tatters.
Because of the extra tension around the high-profile failure, the team leapt into a practice that we weren’t prepared to follow through on. The thinking was that comprehensive testing would have prevented the incident, true in theory, but in practice, the kind of unit testing usually contemplated by TDD wouldn’t have saved us from the cause: incorrectly configured infrastructure. A different test effort would have been more appropriate.
Placing our actual problem in the light of principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, we might have recognized that we already had the skill set on the team for the kind of testing that was needed, we just needed to do it.
I tend to approach things from a physics framework. And physics teaches you to reason from first principles rather than by analogy.
— Elon Musk
When it comes time to consider what technical practice would best serve the future to the team, avoid reacting to circumstances. Take it back to first principles, evaluate the strengths and weaknesses of the team in the context of the kind of work you need to get done and plan for your practice adoption with the kind of consideration you give to planning any long journey.
Heaven supports worthy aims.
— Sancho Panza
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.