Without a bit more context it's unclear that it was this bad. It sounds like the removed it for one day and then put it back in. This may have been the only way to effectively notify people still relying on it.

We had a deprecated server that we wanted to decommission. We announced this to the entire company. We pointed everyone to the new server, and asked for feedback if it couldn't fulfill any needs that the previous one did not &c. &c. We announced the date the server was going down. We inspected logs and guessed who might still be using it from IP addresses (one of the many reasons for wanting to deprecate the server was there was a single shared login for everyone using it :/)

Finally, on the announced date, we just unplugged the Ethernet cable and got contacted by several different people freaking out, wanting to know what happened to the server. We (as planned) plugged the cable back in and then asked them the same questions that had gone out globally. A month later the server was finally offline for good.

One way of interpreting this is that we unplugged the cable to "send a message" but we obviously did discuss the deprecation with lots of people ahead of time.

Those aren't the same thing. A deprecation is a change in contract. A change in contract has to be worked out with consuming teams. In fact that's the whole point of deprecation: to kick off the migration process. Still need the rest of the process.

In contrast, this is about internals, stuff that was never part of a contract but that people use anyway. It comes up a lot in JS because the language doesn't enforce privacy. And it's super painful to not be able to change stuff you never made part of a contract--it freezes your whole codebase.

Is changing internals other people have come to depend on a good idea? Depends on a ton of context, but you should strive for a technical culture that allows this.

None were quite so dramatic but I've worked with a few people with this kind of attitude. All of them were more interested in chasing shiny things and their own personal projects than in getting actual valuable work done.

I sort of disagree. The best way to make people not rely on a behavior is to not have that behavior. If you want to be very, very sure that nobody relies on your service having very high availability, forcibly reduce its availability. Make sure it fails some small percentage of the time.

Similarly here, if you need to make sure nobody's depending on this thing, change its name regularly. Append a random number to the end of it and change it with each minor release or something.

Now, what you do NOT want to do is randomly pull the plug on your service or change the internals exactly once, with no notice, after a long time of stability. That's not helping people know not to rely on it; that's just hurting people who didn't read the sign. Quietly putting up a "deprecated" sign without ensuring people have time or opportunity to read it, waiting an unreasonably short time, and then breaking things is basically a Douglas Adams storyline more than a development practice.

Deletion is not deprecation. Deprecation informs of a potential future deletion.

I worried somebody would interpret my tweet like this. This is not a fair description of what happened, and it seems like I'm throwing my coworker under the bus by allowing this implication.

When we're deprecating things, we normally keep them for years. In this case, this was not about a deprecation. It's about a case where internal properties were used with a clear agreement with our team that they are not supported, we will remove them without warning, and that the consuming code should always be ready for them to be removed.

When my coworker removed them, he didn’t “just” delete them but he shimmed it so that the consuming code would not crash (but also would not get the functionality). That’s the agreement we had with the teams when these dependencies were added.

The “sending a message” part was that despite our initial agreement, the features were nevertheless being depended on more seriously, and it wasn’t until after this incident that the severity was understood.

One method I've seen used to motivate people to move away from deprecated API is: after deprecation is announced, in addition to print a length warning message, also add a thread-sleep call, with the sleep length gradually increasing over time. Consequently, the API will remain usable for maybe months after deprecation, but eventually it will become unbearably slow to discourage any continued usage.