Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

From the thread:

> at one point one of my teammates who is usually very calm and composed deleted some of the internals to “send a message”, which was reverted the next day because it broke a bunch of things for different teams. we didn’t do this again but this started a conversation

Oof. I worked with some people who would declare things deprecated, not discuss the deprecation with anyone, and then remove the deprecated code a short while later even if it was still working just fine.

Same logic: They wanted to "send a message". And it sucked for everyone. Many meetings were had and we usually had to get management to force them to put the (still working) code back and coordinate with other teams on a deprecation schedule.

Please don't force-deprecate things within a company to "send a message" like this. (Note: It wasn't Dan Abramov who did this)

View on HN

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.

I too have learned the value of "turn it off and see who complains" as a last-ditch effort at determining who is still using something and why. It is remarkably effective. However, in at least one case it did take almost an entire week for someone to notice and complain.

This method caused a $10 million dollar, 10 hour long outage at a previous company. You should probably consider who will be complaining in the risk analysis before doing it ;P

There’s honestly no other way to do it. We did this way back when with TLS 1.1 depreciation. We couldn’t use “has anyone connected with TLS 1.1” because all that told us was someone had support for 1.1, not if they could support 1.2. So we turned it off intermittently with increasing frequency to try and generate support tickets.

Oh, a scream test. (At least, that's what we called it in the context of infra/ops at a previous company; I think that's a widely used term)

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.

JS does support private implementation details using closures, but JS devs tend not to use them.

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.

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.

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 want to try to correct the record a little bit: https://news.ycombinator.com/item?id=30201203

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.

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

Reply on news.ycombinator.com