2024-04-13 - Cameron Harder-Hutton
So you want to deprecate something, and you've built the new thing.
Your team should be responsible for software you want to deprecate, because:
It ensures you're in touch with your customers.
There are parts of your software that your customers love and hate. Do you know what they are? The best way to do this is to be the first point-of-contact for your customers when they need help.
It also forces you to have a good answer to the question: 'Why is this deprecated?' If you can't explain to your customers why it's deprecated, and why the future is bright for the new software - is deprecation the right thing to do?
You have skin in the game.
You're motivated to deliver early and properly on the new software. You can alleviate whatever customer pain points you can't fix easily in the old system. And, the faster you finish (properly) the faster you don't have two things to maintain.
You have autonomy to deprecate incrementally.
If you own the old and the new, maybe there is an opportunity to keep the deprecation opaque to your users (if you can, you should). Or maybe, you can use the old system as a 'shim' to the new one, thereby giving everyone lots of confidence when it's time to switch their API calls.
The key point here is you shouldn't build a whole new system that is just 'better', then get every client to migrate their API calls (or worse, get customers to migrate their processes). This approach is risky. Change as few things at once as possible. Entropy and risk never arrive by themselves.
P.S. What if there is no new thing? Read this.
Have any thoughts? Send me an email!