4 ms·

> 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 au

> 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.

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.