[TomSwirly]

> 50-line code changes are reviewed and merged ~40% faster than 250-line changes.

Reviewing a 50-line code change in 60% of the time it takes to review a 250-line code change means the shorter code review takes _four times_ as long to review per line.

[HPsquared]

Also splitting the 250-line change into 50-line parts will probably involve more total lines - to ensure it can be done piece-by-piece then fit together later.

So not only is it more time per line, it's also more lines.

Basically the only benefit is PRs per day, which is... not useful in itself.

[danpalmer]

There are two ways of looking at this, I think the author took the positive way, and you've taken the negative.

You could argue that shorter PRs are easier to review and therefore people are doing more review, and that should result in better changes (indeed the 15% fewer reverts supports this).

Or you could argue that shorter PRs are harder to review as they have less context, and therefore more time is taken but that a better output is not necessarily being reached.

I think both of these are entirely plausible, and the truth probably depends on other process factors.

[mewpmewp2]

It is also going to be more reverts.

If you split 200 lines of code into 4 x 50 you are actually going to have 0.85 x 4 reverts or 3.4x reverts with this strategy.

But overall the whole data is terrible and infuriating because likely the changes are very different in the dataset depending on the loc.

[tmjdev]

To say it another way, you should not expect more code to be merged in the same amount of time as less code. 250 lines is 5x more code, so what is the purpose of a statistic showing 1/5 of the code gets merged faster? That's not a good or a bad thing.

Unless the metric is actually 40% faster per LOC but that's not specified.

[RHSeeger]

Which seems to indicate fairly clearly that, at least as far as time investment, 50 line PRs are objectively worse than 250-line PRs.