Deprecate Like You Mean It
18 points by rbr
18 points by rbr
i honestly think that an added artificial delay on deprecated features is a genius idea
This is too clever. Deprecation is a social problem, and your issues will be full of unhappy people if you give them bad or delayed responses.
Edit: They added a sarcasm tag. Whew.
This is worse than just removing it, creating insidious bugs that will be hard to track down.
Also, in the example of the Python library, they could just have kept the 5 lines of code. There seems to be a recurring theme this year of breaking compatibility for no significant upside.
Yes! So much of upgrading is just churn for churn's sake. For a lot of stuff, you should just mark the old API as deprecated, hide it in the docs/autocomplete, and then leave it there forever because it's not hurting anyone to leave it. There are some tradeoffs when you need filesize to be small and you can't dead code eliminate certain paths, but that shouldn't apply to a Python program.
Conversely, if people are unwilling to make an easy change like this, it suggests that they're going to be unwilling to make changes for APIs that there's much better reason to deprecate and remove because they have correctness issues or are a pain to implement.
(I'm currently dealing with a thing at work where we're having to get customers to migrate off of an old deprecated API and, despite providing them with a migration path, it can be absolutely like pulling teeth.)
I just realized this is the same author as https://entropicthoughts.com/you-want-technology-with-warts. Why do they now want to break software in subtle ways?
Every single wart that annoys us today, used to be a reasonable feature that someone relied on in their production code. Every wart we see today is a testament to the care the maintainers put into backward compatibility. If we choose a technology today, we want one that saves us from future maintenance by keeping our wartful code running – even if we don’t yet know it is wartful. The best indicator of this is whether the technology has warts today.
I realise now the sarcasm didn't quite come through in this article. Oops!
This is sarcasm/parody, right? It’s such a spectacularly bad idea I have to hope so.
But then, some people seem to be taking the idea of adding an artificial delay seriously, which would be perhaps an even more stupendously bad idea, making the treachery even more unlikely to be discovered, and making everyone’s life harder.
I don't like this strategy (wrong results!), and especially I don't think it works for libraries. But it rhymes with a strategy I've used for deprecating network services and APIs, which is to impose "brownouts".
Effectively, if we knew we were going to shut down a service in (say) three months, we'd schedule weekly brownouts in which the service would be unavailable for a defined period. In some cases we kept the service up but artificially increased the error rate to something really high and noticeable, say 20%.
We pre-announced these periods, proactively contacted key customer teams, tried to be as loud as we could. But they always led to some users seeing errors and contacting us with complaints, at which point we could point to the announcements and remind them to migrate.
This reminds me of an incident I experienced working at a large web hosting company over twenty years ago. I worked the night shift monitoring the network when the power went out. There was a lot of scambling in trying to resolve the root issue, but the generators kicked and nothing really went down. Turns out, the building owners had scheduled a backup generator test but the memo literally got lost in the mail.
I had no idea this was satire! I guess I need to recalibrate my sarcasm detector.
I understand it's more comfortable/easier to "leave the warts", but it seems to me there is also a time and place for removing APIs that genuinely cause problems. E.g. I can imagine for unsafe crypto APIs that should be an option.
Edit: I guess part of what tricked me into it is that the core concept of the article resonates with me: sometimes, instead of having a sudden increase of some cost (= sudden API removal), we prefer systems where we can spread out the cost over time.
E.g. I can imagine for unsafe crypto APIs that should be an option.
Notoriously compatible Go has opted to panic if you ask for an RSA key with less than 1024 bit because that’s wildly insecure. They’ve also removed support for SHA1 certificates. For a while these things can still be enabled with a GODEBUG setting.
But notably these are fixes for very clear risks, not changing a function’s name.
What if, instead of returning wrong data, deprecated functions crashed the program every now and then? ISTR GitHub Actions doing this when it was retiring runners on particular operating systems, and while it does mean that you can retry to force something through, it does incentivise moving across to the modernised way of doing things.