5 ms·
The article didn't mention the big advantage (in my mind) of forced migrations: the migration actually gets done. I've worked at places that have done it both
by adrianmonk 5y ago
The article didn't mention the big advantage (in my mind) of forced migrations: the migration actually gets done.
I've worked at places that have done it both ways (forced migrations vs. ways to do migrations later when convenient), and when you can do the migration later, it often ends up being much later, sometimes infinitely later (i.e. never).
Do you want all the pain of migrating now? Or do you want to spread the pain over a longer period of time?
If the breakage is due to incompatibility (the API behaves differently, etc.), then breakage that the migration caused is probably still going to happen if you do the migration later. So you're not reducing the total amount of breakage/pain.
And if you spread it over a longer period of time, you are increasing the maintenance burden on the team that needs to provide compatibility with the old and new ways.
- tehjoker 5y agoI don't think they're wrong about the inefficiency of it all being psychically damaging though. I wonder how many dependencies the average project has and how many projects each engineer has to get a rate of breakage that high.
- lmm 5y agoProbably the technically best client I worked for had a 6 month rolling deprecation cycle. Every library must release at least every 6 months (or, in the case of an external library that hasn't made a release, the dedicated internal maintainer for that library must assert that the library is still being maintained). If you depend on something that's more than 6 months old, your build fails. Everyone was forced to do their migrations (exemptions would generally be approved but only once). But they had fair warning and could schedule it to fit in with the rest of their work.
- anothernewdude 5y agoOr the migration doesn't get done and Google kills yet another product.