That would only result in everyone entering their own version of what they believe the data should be structured like, making it a completely mangled shitshow without a shred of consistent workflow across the company. As soon as the user has the ability to deviate from the standard data format they will do so, just because they personally want it differently. It’s an absolutely horrible idea.
That would only result in everyone entering their own version of what they believe the data should be structured like, making it a completely mangled shitshow without a shred of consistent workflow across the company.
Hee hee, this reminds me of a job I had a couple of decades ago with a company that made software for Clerks of Court offices. I got a bug ticket that said a “States” picklist in the application had a “few” weird entries in it. I checked the DB and found a States table with 511 entries in it – the 50 normal two-letter abbreviations for US states plus the territories, and hundreds of things like “Lousiana” and “Louisana” and “Louisianna”, and even countries like “Frantce” and “The UK” and whatnot (this experience scarred me and I now have great difficult spelling Louisiana properly). Turns out the States table had originally been pre-populated with the proper abbreviations, but another programmer had gotten the job of automating a marriage form that had a line for indicating which state each person came from. The form dated to the fucking 1800s but they had subsequently used the line for generally stating where each person was from. The programmer was obsessed with relational DBs so he tied this field into the States table but wrote code to add new entries to the table if what clerks typed in wasn’t already there.
This polluted every other place in the application that had a states picklist. How it got to 511 entries before anybody reported a problem is a mystery to me.
Fun fact: the cost of this software was $50,000. Per month. All 64 parishes in the state paid that fee. The application was written and maintained by four programmers, three of whom were morons (I’m not saying whether or not I was one of the three).
I mean, technically most mainstream examples support basically any kind of entry restrictions you can think up, including structured data forms and even binding values to current db constraints but of course the do-anything-super-sheets I’ve come across in the wild aren’t that. Usually improvised tools from a company’s early bivouackers focused on short term enablement rather than long term maintainability.
That would only result in everyone entering their own version of what they believe the data should be structured like, making it a completely mangled shitshow without a shred of consistent workflow across the company. As soon as the user has the ability to deviate from the standard data format they will do so, just because they personally want it differently. It’s an absolutely horrible idea.
Hee hee, this reminds me of a job I had a couple of decades ago with a company that made software for Clerks of Court offices. I got a bug ticket that said a “States” picklist in the application had a “few” weird entries in it. I checked the DB and found a States table with 511 entries in it – the 50 normal two-letter abbreviations for US states plus the territories, and hundreds of things like “Lousiana” and “Louisana” and “Louisianna”, and even countries like “Frantce” and “The UK” and whatnot (this experience scarred me and I now have great difficult spelling Louisiana properly). Turns out the States table had originally been pre-populated with the proper abbreviations, but another programmer had gotten the job of automating a marriage form that had a line for indicating which state each person came from. The form dated to the fucking 1800s but they had subsequently used the line for generally stating where each person was from. The programmer was obsessed with relational DBs so he tied this field into the States table but wrote code to add new entries to the table if what clerks typed in wasn’t already there.
This polluted every other place in the application that had a states picklist. How it got to 511 entries before anybody reported a problem is a mystery to me.
Fun fact: the cost of this software was $50,000. Per month. All 64 parishes in the state paid that fee. The application was written and maintained by four programmers, three of whom were morons (I’m not saying whether or not I was one of the three).
I mean, technically most mainstream examples support basically any kind of entry restrictions you can think up, including structured data forms and even binding values to current db constraints but of course the do-anything-super-sheets I’ve come across in the wild aren’t that. Usually improvised tools from a company’s early bivouackers focused on short term enablement rather than long term maintainability.