[ignormies]

Something I often use stacked diffs for is deprecation -> removal flows.

1. Deprecate old feature + add opt-in support for replacement 2. Make replacement default with opt-out for old pattern 3. Completely remove old feature and the opt-out functionality

I can write the entire stack of diffs upfront, have them individually reviewed but still linked, and ensure they're merged in the correct order.

The bottleneck for merging isn't in the review process, but in the deprecation. It wouldn't make sense to land all three of these changes as fast as review/merge would allow; that would skip the deprecation period.

[wpietri]

Ooh, good point. I'm suspicious of stacked diffs generally, but this seems like a good example where we truly don't expect to learn anything after the initial deploy.

[kqr]

But is it really effective use of your time to make changes to the code that you know won't be relevant for weeks or months? You could spend the same time on other changes that would start earning you money tomorrow, instead.

[tablespoon]

> But is it really effective use of your time to make changes to the code that you know won't be relevant for weeks or months?

It totally is, because it doesn't wastefully discard the mental context needed to make the follow on changes. Task switching unnecessarily incurs significant costs.

> You could spend the same time on other changes that would start earning you money tomorrow, instead.

Maybe in some bare-bones startup context that can't afford to think beyond next week, but most organizations aren't like that.

[majormajor]

Sometimes?

Consider also the stakeholder who gets annoyed whenever the dev team wants to work on something that would take longer than a week to turn around, and limits the things they'll ask for to those estimated at a week. So bigger things can never get done at all, and you'll just be looking for a local maxima instead of having the chance to make more significant changes.

Sometimes it's worth it to prep and clean up as you go. Knowing when it's worth it and when it isn't is one thing that makes some devs more valuable long-term than others.

[smaudet]

Agreed, sizing is one of the things that can set apart devs, either due to experience, knowledge, or some combination of both.

[ignormies]

Having the change implemented from start-to-finish demonstrates a finished and thorough design. It also allows review to happen with the complete change at the forefront of the reviewers' minds.

Kicking the completion of the implementation of a change you've started landing to an unspecified future date indicates poor engineering rigor imo. It's just begging for the change to perpetually be half-migrated and never finished.