Operations: Can you exclude some user records for the website? These are obsolete and we don’t want users to access these anymore.

Me: So what are you using to indicate the record is obsolete?

Ops: We changed the last name field to say “shell record - do not use.” Sometimes it’s in the first name. Actually, it gets truncated to “shell record - do not u”.

Me: A…text field…and you’re totally ok with breaking user accounts…ok ok cool cool

Not cool 😳😬🤬 I’m not causing more chaos because your record keeping has gotten messy

Give it to them if they put their requirements in a ticket.

Don't stress out about the small shit.

Just make sure that your hesitancy is documented and they have rejected your input.

When the great calamity begins, refer to the ticket.

I'm sick of saving these assholes from themselves.

I'm actually thinking about getting tshirts made with my new catchphrase.

"Fuck'em"

@sariel I’d buy that T-shirt

Sounds like a two minute fix... and they are obsolete accounts, so what's the problem?

@ultrageoff the problem is that they're overriding a use of a field that already has a use.

You don't override the purpose of a field just because it's easy.

Secondly, what happens when someone typos the value and it doesn't match what you're looking for? Now there's 100 accounts that are *supposed* to be blocked but aren't.

Thirdly, indexing off of a string value that a person inputs is bad juju for database efficiency. You would reduce DB response times by 80% if you just used a bool over a varchar.

@ultrageoff not a two minute fix. Ops decided the records for system A are obsolete because they were de-duping records. but they didn’t realize the ones they chose to make obsolete are associated with active user accounts in system B. Marking as obsolete in one system doesn’t change its use another one. System B needs the record in system A.

@sariel 💯++

@sariel While I 100% agree that it's insanity to mod an existing field like that (might become a huge issue for validation later that you now can't tell who is removed and you have 42 "John shell record") I would Legit be prepared to anser questions like "if you copy paste a string is it really a significant error risk?" and "I know you devs insist on performance but a lookup of a string vs a bool - is that even 5 ms more?"

But why are they not allowing a bool field eg “isObsolete”? It’s way less work and less bug prone.

@TeachMeCode Just a wild guess but DB model changes could have unexpected impacts on mapping and might require multiple codebases to change their data structures - while value changes do not.

@jiraTicket I made that exact argument many years ago. I placed my trust in the user to be able to follow a simple task such as copy & paste or at the very least type in a four letter word. I went as far as to change it to, "just delete any content in that field".

I found out that users are smelly, sticky handed, retarded toddlers that do not deserve a developers trust. I am now one of those devs that actively wants to make things so strict on the user that there's zero flexibility in the application for the following reasons.

The outcome was a mixture of tabs vs spaces, non-utf8 characters, caps vs no caps, and a complete nuke of ALL field values. They complained that I shouldn't have allowed them to do those things, and once I corrected it they complained that it was too difficult to remember to check or uncheck a box.

Also, I wonder how long a non-indexed query would take against a table that holds over 10 million records? Too long IMO.

I think maybe part of the problem here is the requesters are delving into the implementation instead of just requesting the feature - i.e. "we are making things obsolete by bastardising an existing field" instead of "hey mr dev, we need a way to mark accounts as obsolete, which has xyz implications in the rest of the system"