[ricardobeat]

> By deploying small changes often, you get deliver value much sooner and fail smaller.

Which increases the number of changes per deployment, feeding the overhead cycle.

He is describing an emergent pattern here, not something that requires intentional culture change (like writing smaller changes). You’re not disagreeing but paraphrasing the article’s conclusion:

> or the harder way, by increasing the number of changes per deployment (better tests, better monitoring, better isolation between elements, better social relationships on the team)

[sourceless]

I am disagreeing with the conclusion of the article, and asserting that more and smaller deployments are the better way to go.

[ricardobeat]

You are not. The conclusion of the article is the same, you "need to expand the far end of the hose" by increasing deployment rate or making more, smaller changes. What was your interpretation?

[sourceless]

My reading was that there were two paths the author highlights:

1) Increase deployment capacity (which I'm reading as frequency, and I fully agree with)

2) Increase change capacity per deployment by making it less likely that a set of changes will fail through tests, monitoring, structural, and team changes

#2 is very much geared to "ship more changes in one deployment" which is where my disagreement lies. I think you should still do all those things, but that increasing the size of the bundle is explicitly an anti-goal.

I think you're better off, as a rule of thumb, making fewer changes per deployment if you want to reduce risk.

But -- that is my particular reading of it.

[sciurus]

My reading is that the author posits there is a fixed amount of change that can be safely made in a single deployment. The solution is to make it possible to deploy more frequently. This is hard, so organizations will often instead introduce overhead that slows down changes. Engineers might be tempted to blame the overhead and try to eliminate it, but that won't be successful and may even backfire. They need to tackle the underlying issue of deployment capacity instead.