There’s a similar problem that comes up in business often enough, where a change in your software leaves behind “legacy” code or data. When developing you almost always have to write things such that the new model and old model can live side by side, and customers using the old model can (at least for a time) just keep going while new users go on the new model.
Whenever a project like this is done, it’s very tempting from a business point of view to just leave the “legacy” users / data alone. But, technically, all your code continues to have to support two different models. Yes, with the right abstractions you can make this work without being terribly painful, but in practice there are always rough edges.
The time and effort it would take to migrate the old stuff into the new format is high, and the perceived business value is low. In many cases the migration never happens, and the old code is never removed.
But the problem is, you are now paying a tax to deal with that old code for all time. Every time a decision like this is made, the tax goes up. The tax slows you down, and it makes all future work you do more complicated.
So, there is a game theory problem here: for each individual decision, it arguably makes more sense to leave the legacy case alone and move on. But if you choose that path every time, it is a mistake, because the costs compound.
So far, the only thing I’ve seen that prevents this is very strong technical leadership that ensures the migration is baked into the project and made non-optional to the business teams. That’s really hard to do though, and arguably not always the right decision for the business, which may need to move fast now just to survive.
Whenever a project like this is done, it’s very tempting from a business point of view to just leave the “legacy” users / data alone. But, technically, all your code continues to have to support two different models. Yes, with the right abstractions you can make this work without being terribly painful, but in practice there are always rough edges.
The time and effort it would take to migrate the old stuff into the new format is high, and the perceived business value is low. In many cases the migration never happens, and the old code is never removed.
But the problem is, you are now paying a tax to deal with that old code for all time. Every time a decision like this is made, the tax goes up. The tax slows you down, and it makes all future work you do more complicated.
So, there is a game theory problem here: for each individual decision, it arguably makes more sense to leave the legacy case alone and move on. But if you choose that path every time, it is a mistake, because the costs compound.
So far, the only thing I’ve seen that prevents this is very strong technical leadership that ensures the migration is baked into the project and made non-optional to the business teams. That’s really hard to do though, and arguably not always the right decision for the business, which may need to move fast now just to survive.