[dsnuh]

Funny story... We had a contractor start named "John Smith" and this guy just could not get on the domain, receive email, etc. All his shit was just not working until like a week after his start date.

My team doesn't handle new user creation, and it's a big company, where sometimes other teams may as well be other companies. I kept getting tickets from this guy and he's reporting that none of his stuff works. There's nothing I can do, but I try to help the guy out.

Anyway, a week later his stuff works. I guess whatever team does the new user creation never planned for there to be more than four employees with the same name, and their automation broke on "johnsmith5". Sigh.

[sillysaurus3]

I'm trying to imagine the architecture that led to this.

[dsnuh]

Trust me, I couldn't imagine it either. My guess is it actually probably broke on the second John Smith that joined, and they had to manually configure all subsequent John Smiths, and they just wait until they get a ticket.

[elcritch]

Alternatively a dev thinks gotta handle user name collisions: "try creating user... hmmm if exists append ‘1’ and repeat with 2..n+1, oh uhhh, better stop after, idk, 5 times (last time my test borked and filled up the database with username ‘(null)’ last time, sigh)". Programmer takes lunch.

[fooker]

A plain fixed size C array embedded in some data structure somewhere?

Doesn't seem that big a stretch to imagine.

[dsnuh]

This would be more like Windows batch jobs or Powershell scripts. I honestly think it just cannot handle duplicate names at all, and they wait until they get a complaint. When we were acquired, we had a person on our team receieiving emails for a different user with the same name that previously existed in the company that acquired us.