Hacker News Reader

Comment by chefandy | Hacker News Reader

This is fundamentally a support and UX problem, not a dev failure. Big production user management and authentication systems can get pretty complicated and trying to figure out every weird edge case when combining them is not low-effort by any measure. "What if someone's username wasn't caught in their profanity filter but gets caught by ours" seems like a pretty rare edge case in a huge pool of big problems to solve. Their shortcoming was not giving their users proper guidance on how to address the inevitable kinks that pop up.

View on HN

Anecdotally, having worked on identity management systems, and merged a number of them, this hasn’t ever seemed like an edge case for me. It’s pretty high up on the list. I’d imagine the folks they’ve got working on these systems are paid an order of magnitude more than myself.

> I’d imagine the folks they’ve got working on these systems are paid an order of magnitude more than myself.

I wouldn't assume that. Game companies are notorious for pinching pennies. In fact, I wouldn't be surprised if these systems were outsourced completely.

You seem to be confusing when two systems don't mutually support certain names due to technical limitations, with what happened here.

It's not a bug that a filter caught names that the merged companies now collectively do not allow in their collectively owned games.

The only miss here is more of a UX issue: they handled username bans the same way they handled all bans, with a shadowban.

Shadowbans are great for most infractions since you burn some time of the offender before they start again and give them little information to find loopholes with... but for something rectifiable there should be a way to nudge and explain why they're banned.

I think it's really easy to say that without knowing anything about what they actually did.

I don’t think it’s solely a dev responsibility, but having worked in a UX role on a project that merged two systems with user accounts and millions of users, we (UX, dev, product) spent a lot of time thinking of scenarios exactly like this.

You’re right, this was a support failure, but it was also a failure of the team(s) that performed the merge.

And who knows how many other scenarios they considered? The reason it's a lot of work to ferret these situations out is because there are a ton of things that can go wrong. Who knows how many other situations were considered? For this to be a development failure, we'd need to see a pattern. One instance doesn't make a pattern.

1. How would you know about the users that were missed? Just because they haven't complained, it doesn't mean that everything was alright.

2. Why do you think that B/A haven't spent a lot of time thinking of scenarios like this?

Reply on news.ycombinator.com