User Ingenuity vs. Developer Deprecation Strategy
Description
A two-panel meme contrasting a developer's intention with a client's reality. The left panel is captioned, 'Me making a deprecated feature hard to use so I can get rid of it,' and shows a building entrance blocked by a dense grid of upright metal poles, a form of hostile architecture designed to prevent loitering. The right panel, captioned 'The client gettting used to it,' shows a person who has placed a mattress atop these poles and is comfortably lying on it, using their phone. This meme humorously illustrates the futility of trying to force users away from a feature they like. Developers may try to 'sunset' a feature by making it inconvenient, but resourceful users will often find a way to adapt to the changes rather than migrate, creating unexpected workarounds and dependencies on the very 'hostile' environment created for them
Comments
10Comment deleted
The fastest way to make a feature 'critical infrastructure' is to deprecate it. Users will build entire workflows on top of the 'do not use' warnings
Deprecated v1 behind captchas, 429s, and a scheduled 410; the client wrote a Jenkins job that OCRs the captchas, retries on 429, and still demands a 24×7 SLA - legacy APIs are cockroaches with a budget
We spent three sprints implementing rate limiting, removing documentation, and adding deprecation warnings, only to discover the client wrote a wrapper that polls harder when throttled and filters out our warnings
The eternal optimism of deprecation warnings: you add friction, remove documentation, and mark it @Deprecated(since='2019', forRemoval=true), yet somehow production traffic to that endpoint keeps growing. Users don't migrate - they evolve. They'll build entire CI/CD pipelines around your intentionally broken API before they'll read the migration guide. It's the software equivalent of finding out your 'temporary' Kubernetes workaround from 2018 is now load-bearing infrastructure supporting $10M ARR
Soft-deprecation strategy: rate-limit, scary warnings, awkward OAuth. Enterprise client: built a proxy, wrote a runbook, got it blessed by change control - congrats, the obstacles are now part of the SLA
I tried to kill the legacy endpoint with nag banners, 429s, and awkward OAuth; the client shipped a ‘compat’ sidecar with a policy exception - now my workaround has an SLO
Classic deprecation ploy: lace legacy API with 429s and cryptic schemas; clients spawn a Kubernetes namespace just to curl it comfortably
That actually seems to be nicer than lying on the ground. Less animals and bugs, better heat isolation, no trash. Comment deleted
when the side effects are actually benefits for the client Comment deleted
you make a good product @ complete failure @ try to make product hard to use @ success that was unseen before Comment deleted