3 ms·

I work at a company mentioned in the article (Etsy). I've also worked in environments with daily cuts; these feel similar in practice. Having the ability to do

I work at a company mentioned in the article (Etsy). I've also worked in environments with daily cuts; these feel similar in practice. Having the ability to do continuous deployment is not the same as practicing continuous deployment. You don't buy much if developers still yolo-push 6000 line commits with fully baked features. You still need to foster a strong developer culture that encourages small changes. This is true outside of continuous deployment. But since you gain the option to deploy small and isolated changes to production, the consequences are much different. This has many implications. It needs to be OK to push back and ask engineers to split large code commits into smaller units. Engineers need a strong understanding of how to sequence changes: "I need to do the ORM changes, then the API endpoint, then the controller change, and then I can do the frontend." This means that senior engineers invest time in helping junior engineers understand why this has to be done and why this particular sequence is safe. Methods need to be devised to avoid holding up future pushes - for instance, a culture of rolling back to safety at the first sign of trouble instead of debugging in production. Anecdotally, the best developers seem to always be pushing small changes, or always have a few commits in the daily cut. Interpreting this is a bit of a chicken and egg problem - is throughput higher because the changes are smaller, or does high implementation volume just imply more changes? Or maybe it's just a free form of advertisement: "I always see that X is pushing, so they must be good"

klenwell 9y ago
> Anecdotally, the best developers seem to always be pushing small changes More formally, this is true, too. At least according to Donald G. Reinertsen, the author of this book: https://www.goodreads.com/book/show/6278270-the-principles-of-product-development-flow https://www.goodreads.com/book/show/6278270-the-principles-o... Batches and queues are primary themes of the book and Reinertsen waxes prosaic on the extensive benefits of making batches smaller all around during product development. I've noticed the benefits mainly with user story size and pull request size (which are generally correlated). Large batch sizes lead to longer delays which lead to cut corners which lead to more defects which lead to further delays. There are other underestimated penalties that Reinertsen discusses as well. Of course, too small and you're incurring disproportionate overhead with each batch. The key, I suppose, is figuring out mama-bear batch sizes for your team or organization and effectively paring down to them.
- curun1r 9y ago
  There's a quote from Blaise Pascal that captures my feelings on small changes fairly well: "I have made this longer than usual because I have not had time to make it shorter." Small changes mean front-loading a lot of the thought into breaking down the problem. Large stories/changesets is often a sign of a vague requirement or design up-front where the developer mostly figures out how to solve the problem while writing the code. It's not really the size that's the problem, it's the uncertainty. But the size is much easier to observe and use as a forcing function for increased planning (i.e. large stories need to be broken into smaller stories before a developer can start work.) When you talk about the best developers being the ones that push small changes, what I believe you're really saying is that the best developers are the ones that are able to be given a large problem and break it down into its constituent parts most easily and the ones that have the discipline to do that in planning rather than while coding. Which, to me, is a lot less controversial statement.
twoodfin 9y ago
Anecdotally, the best developers seem to always be pushing small changes, or always have a few commits in the daily cut. Interpreting this is a bit of a chicken and egg problem - is throughput higher because the changes are smaller, or does high implementation volume just imply more changes? Or maybe it's just a free form of advertisement: "I always see that X is pushing, so they must be good" This is a really interesting question. I agree that better developers have a natural inclination to break down large changes into small, self-supporting chunks. But I do worry that this approach can be doomed to stick at a local maximum.

klenwell 9y ago

> Anecdotally, the best developers seem to always be pushing small changes More formally, this is true, too. At least according to Donald G. Reinertsen, the author of this book: https://www.goodreads.com/book/show/6278270-the-principles-of-product-development-flow https://www.goodreads.com/book/show/6278270-the-principles-o... Batches and queues are primary themes of the book and Reinertsen waxes prosaic on the extensive benefits of making batches smaller all around during product development. I've noticed the benefits mainly with user story size and pull request size (which are generally correlated). Large batch sizes lead to longer delays which lead to cut corners which lead to more defects which lead to further delays. There are other underestimated penalties that Reinertsen discusses as well. Of course, too small and you're incurring disproportionate overhead with each batch. The key, I suppose, is figuring out mama-bear batch sizes for your team or organization and effectively paring down to them.

curun1r 9y ago
There's a quote from Blaise Pascal that captures my feelings on small changes fairly well: "I have made this longer than usual because I have not had time to make it shorter." Small changes mean front-loading a lot of the thought into breaking down the problem. Large stories/changesets is often a sign of a vague requirement or design up-front where the developer mostly figures out how to solve the problem while writing the code. It's not really the size that's the problem, it's the uncertainty. But the size is much easier to observe and use as a forcing function for increased planning (i.e. large stories need to be broken into smaller stories before a developer can start work.) When you talk about the best developers being the ones that push small changes, what I believe you're really saying is that the best developers are the ones that are able to be given a large problem and break it down into its constituent parts most easily and the ones that have the discipline to do that in planning rather than while coding. Which, to me, is a lot less controversial statement.

twoodfin 9y ago

Anecdotally, the best developers seem to always be pushing small changes, or always have a few commits in the daily cut. Interpreting this is a bit of a chicken and egg problem - is throughput higher because the changes are smaller, or does high implementation volume just imply more changes? Or maybe it's just a free form of advertisement: "I always see that X is pushing, so they must be good" This is a really interesting question. I agree that better developers have a natural inclination to break down large changes into small, self-supporting chunks. But I do worry that this approach can be doomed to stick at a local maximum.