> The goal is not 1,145 deployments per day. It's removing the friction that makes that pace impossible. What's really stopping you from rapidly shipping value to users?

But you haven't identified any value, just mindless cited some throughput stat. Merge your code changes in 1-letter increments and you can juke the stats even higher!

That would be clearly malicious with the goal of gaming stats and not bringing any value. I doubt that such dumb behavior would go unnoticed for any considerable time.

The article states that this comes out to be one deployed PR per 3 days per developer. That is clearly doable and does not require any dumb moves like parent suggests.

One letter increments wouldn’t work because each commit has to leave the program correct. For example committing the first f of a for loop would leave the code with a syntax error. But you often should break up changes into as small as possible commits that leave the code correct. E.g. make one commit that refactors the code (no change in program output), then another change which implements the change in program behavior that motivated the refactor. This generally makes commits easier to review, less likely to contain defects, and easier to attribute bugs and roll back.

I'm not sure why the stat is nitpicked that much. Of course you can completely fake this stat. I have no idea if Stripe does or how much LoC or actual functional changes these deployments do. It's just that they are very confident in shipping changes, all with minimum downtime. Constantly, every day. For a company which does a major part of the financial infrastructure of the web, that's impressive.

In my opinion the goal isn't getting to some arbitrary number, it's making this possible. That there are no process/technical/cultural impediments not allowing you to do changes every single day.