Why Engineers Fight Deprecation
Imagine you've been driving the same car for 10 years. You know exactly where every button is. You know the quirks — that the AC takes 3 minutes to warm up, that you have to hold the key a certain way. Now someone tells you to switch to a new car. Even if the new car is objectively better, you feel a sense of loss. This is the Endowment Effect: humans assign extra value to things simply because they own or use them.
Developers experience this with tools. They will fight to keep a terrible, broken Jenkins server because they know its quirks. They fear the unknown of the new platform. This is not irrational — it is human. A Platform Engineer who ignores this will face passive resistance, missed deadlines, and resentment.
Empathy-Driven Deprecation
The antidote to the Endowment Effect is a communication strategy built on empathy, transparency, and respect for the developer's time.
1. The Guaranteed Sunset Date
Give a clear, fixed timeline — for example, "This system will be shut down on March 1st." Do not move this date, even if adoption is slower than expected. Uncertainty breeds procrastination. When developers know the date might slip, they wait. When they know it won't, they act.
The one exception: if a brownout reveals a critical dependency you didn't know about, it is acceptable to extend the timeline once, with a public explanation of why. Doing this repeatedly destroys credibility.
2. The Tombstone
Visually mark the old system as deprecated everywhere users encounter it. Add a red "DEPRECATED" banner to the UI. Add a warning to every page of the documentation. Inject a deprecation notice into every build log output. The goal is to make the deprecated status impossible to ignore.
3. The "Why" — Make the Cost Visible
Abstract arguments ("the new system is better") are easy to dismiss. Concrete costs are not. Tell developers: "LegacyCI costs $47,000 per month in cloud infrastructure. Shutting it down frees up budget for two additional senior engineers." Or: "This service has had 3 security CVEs in the past 6 months that we are no longer patching." When people understand the real cost of the status quo, they are more motivated to change.
4. The Funeral
This sounds unusual, but it works. When a long-running system is finally shut down, host a brief "funeral" — a Slack post, a short all-hands mention, or even a small team gathering. Acknowledge that the old system served the company well for 5 years. Thank the engineers who built it. This provides psychological closure and reduces the resentment that can linger after a forced migration.
The funeral also signals organizational maturity: we build things, they serve their purpose, and then we retire them with dignity. That is a healthy engineering culture.