One of the primary purposes of batching is to release features at a regular cadence, and all releases go through the same minimum set of checks to catch any unexpected regressions.
In my experience, the workload of these checks grows much slower than linearly with batch size.
I think the article is mostly just confusing throughput and latency. Releasing on a fixed schedule adds some latency, but that doesn't mean there's a bottleneck constraining throughput. And long-term, development speed is determined by throughput, not whether you shipped a feature a few days earlier.
High latency might become a problem if you need user feedback to decide what to work on next, but you don't necessarily need to push everything to production immediately to get feedback. You can have a separate beta/staging system and ask users to check out your new changes there before they get rolled out to everyone.
One of the primary purposes of batching is to release features at a regular cadence, and all releases go through the same minimum set of checks to catch any unexpected regressions.
In my experience, the workload of these checks grows much slower than linearly with batch size.
What other factors am I missing here?
I think the article is mostly just confusing throughput and latency. Releasing on a fixed schedule adds some latency, but that doesn't mean there's a bottleneck constraining throughput. And long-term, development speed is determined by throughput, not whether you shipped a feature a few days earlier.
High latency might become a problem if you need user feedback to decide what to work on next, but you don't necessarily need to push everything to production immediately to get feedback. You can have a separate beta/staging system and ask users to check out your new changes there before they get rolled out to everyone.