Case Wars and legacy twits



  • Okay, so I'm the legacy twit in this story, and I'm referring to many comments I've read on the internet over the decades that talk about some IT manager who's only IT experience was Cobol programming ten years ago.  That's me, except I'm a business analyst instead of a manager, and the Cobol was as recent as two years ago.  I also have web development experience, networking, hardware, tech support and everything else under the sun as you would expect from somebody with a career flowing past two decades. 

    What I want to rant about isn't that my dev team isn't using proper Cobol best practices in their Javascript code.  It's more about what I'm perceiving as sheer laziness that you only expect to see in a "fresher" and should have been thoroughly beat out of you in your second or third year of an IT career.   Specifically, leaving data input methods/routines case sensitive because you can't be arsed to hunt down the case modifying routines in whatever libraries you're using.  The dev lead on my team does this, the devs in the other teams in my company do it.  This week we have a little war going on about some data that is passed through several systems, with each system's dev team claiming it's not their job to fix the case.  (The data is customer names, pulled from an Oracle database and ultimately mail-merged into email templates send to customers.  For the reputation and professionalism of the company, it's better if the customer doesn't recieve emails saying "Hello JOESMITH".)

    Bringing the two issues together, it's all I can do not to thrust my chest out and proclaim how "I learned this lesson about fifteen years ago and why in hell am I having to beat it out of you suckers who are SUPPOSED to be dev LEADS with experience?" because I figure someone will come back with a snide comment about my legacy experience makes me qualified to choose jello or pudding for dinner at the rest home and nothing more.  The joys of aging out of IT....



  • If it's names then avoiding mucking with the case makes sense to me, otherwise you are going to step all over things like 'McCormick'.  Of course if you are doing comparisons then you do them case insensitive.



  • Didn't you get the memo? IT knowledge is useless after 5 years.

    For example, I've lost account of how many times big O notation changed since 2007.



  • @jetcitywoman said:

    an Oracle database

    Is there any company that uses Oracle (including Oracle) not full of lazy developers who don't care about bugs or usability problems?



  • @blakeyrat said:

    Is there any company that uses Oracle (including Oracle) not full of lazy developers who don't care about bugs or usability problems?

    Simple logic refutes the possibility. Oracle is used by big enterprisy companies, and big enterprisy companies are full of people. The more people you have, the greater the chance that any particular trait of humanity will be represented. In the case of laziness, well, that's even worse. People in general are lazy, and the more lazy people you put in one place, the lazier they get. So no, there cannot be any company that uses Oracle that is not full of lazy developers.

    And that certainly includes my own.



  • @jetcitywoman said:

    This week we have a little war going on about some data that is passed through several systems, with each system's dev team claiming it's not their job to fix the case.  (The data is customer names, pulled from an Oracle database and ultimately mail-merged into email templates send to customers.
     

    Presuming that the data is stored in a VARCHAR field and the case will be preserved... is the data actually captured in the correct case, or does it hit toUpperCase() before being stored in the DB?

    If someone's entering it all in caps, then that's how it should be displayed. If someone's app is swapping case mid-way, then it should be them that undoes their damage case changes.



  • Not too long ago, we had built a communication routing thingymabob that would basically take input from misc frontends and send it out to misc backends in the desired format. Basically, a home-grown mini-middleware.

    After things were tested around and deployed, and everyone signed off and was happy, we discovered an interesting bug with one of the legacy backends. Long story short, it didn't support upper-case characters. It couldn't use them in searches or in saves. Reports failed, lookups were silenced, users frowned. I don't know what kind of backend database the ancient ruin was using, but apparently the computer was built before the lower case was invented. We ended up having to drop a toUpperCase() in our system if the input was to be sent to the legacy backend.

    So, this could be similar(ly stupid).


  • @blakeyrat said:

    @jetcitywoman said:
    an Oracle database

    Is there any company that uses Oracle (including Oracle) not full of lazy developers who don't care about bugs or usability problems?

    Do anybody here knows for a fact that Oracle uses Oracle database? They should know better.


  • Discourse touched me in a no-no place

    @locallunatic said:

    If it's names then avoiding mucking with the case makes sense to me, otherwise you are going to step all over things like 'McCormick'.  Of course if you are doing comparisons then you do them case insensitive.

    This. My group NEEDS to muck with capitalization in names (because it's kind of what we do) and we actually maintain a list of naming "rules" (eg "Capitalize the first letter of every word. Capitalize anything that comes after Mc- or Mac-; unless it's a k as in Mack-, except if it's followed up by a vowel as in MacKay; or an h as in Mach") Even then, when we do get customer data that's already capitalized properly, the first and last names go straight into a clever database where we aggregate the number of times a given spelling has been capitalized each way, and where the most common capitalization don't match the rules engine output*, are added to the rules engine as exceptions. We've even considered storing known name/address pairs and using them to make sure we get everybody right (we're big enough that we've almost certainly mailed something to everybody in the US and a fair portion of the rest of the english-speaking world) but that's too expensive for too little benefit.

    All of that is WAY too much work to expect of a company that doesn't make gazillions of dollars on personalized print material (bills, junk mail, anything and everything related to the healtcare industry, high school and university diplomas, etc.) and more recently personalized digital marketing. If you need to change the capitalization on names, you're probably doing something important enough for you to pay professionals to do it for you.

     

     

    *There's a hilarious bug/misfeature here. All it takes is for one person with a funky capitalization pattern on an uncommon name to get an inordinate amount of mail (the easiest way to do this is to get sick or run into financial problems) to screw it up for everybody else with that uncommon name. I've fielded tickets that made their way all the way from some irrationally angry nut, through the entirety of our client's support organization, into and through several operations groups, across to my project managers and downhill to my mailbox. 

     

    Bonus WTF I remembered while writing the previous: One of the applications I maintain builds medical provider directories. I once had a ticket travel all the way from the recipient of one of these directories to me with the question "Why isn't Dr. soandso listed?" After 4 hours of digging in my byzantine database, which was designed by a madman, I discover that the end user's health plan isn't accepted by that doctor. I know for a fact the client has a system geared much more towards humans accessing that sort of data - it's the system that provides my damned data dumps - and I also know for a fact that it's accessible to their frontline phone operators. Instead they opted to get billed a cool $1000+ for the answer to that urgent question and to delay another client's project as a result (in our organization, ANY support issue, no matter how minor, has absolute precedence over ANY new work)

     



  • @Weng said:

    *There's a hilarious bug/misfeature here. All it takes is for one person with a funky capitalization pattern on an uncommon name to get an inordinate amount of mail

    Big S, small A, small N, big D, small e, big E, and there's a little star at the end.



  • @Xyro said:

    Long story short, it didn't support upper-case characters. It couldn't use them in searches or in saves. Reports failed, lookups were silenced, users frowned. I don't know what kind of backend database the ancient ruin was using, but apparently the computer was built before the lower case was invented. We ended up having to drop a toUpperCase() in our system if the input was to be sent to the legacy backend.
    So did it, or didn't it support upper case? Or lower case?

    The TRS-80 model I only knew upper case. I think you needed to buy a disc drive to get lower case.

     



  • @blakeyrat said:

    @jetcitywoman said:
    an Oracle database

    Is there any company that uses Oracle (including Oracle) not full of lazy developers who don't care about bugs or usability problems?

    Yes.



  • @Severity One said:

    So did it, or didn't it support upper case? Or lower case?

    Whoops! Messed that post up. It didn't support lower case. Upper case was the only case.

    I'm fairly certain the backend was some variation of an IBM mainframe, based on the number of older coworkers with mainframe PTSD around here.

    (They're the ones who name things in all caps, sometimes email in all caps, use one directory for everything, and use stupid abbreviations to make sure program names fit into four or so alpha characters with about four random numbers appended to it. They also write procedurally in all languages, somehow. The ones that have managed to learn Java have figured out a way to write a 10,000 line application comprised of one class and one method. What a nightmare they must live in...)



  • @Xyro said:

    Whoops! Messed that post up. It didn't support lower case. Upper case was the only case.

    I'm fairly certain the backend was some variation of an IBM mainframe, based on the number of older coworkers with mainframe PTSD around here.

    So maybe you just were having trouble converting lowercase characters to EBCDIC?



  • @boomzilla said:

    So maybe you just were having trouble converting lowercase characters to EBCDIC?

    Our program communicated to the legacy backend program in ASCII, per the communication spec. The backend listener would then do the conversion to EBCDIC. I guess it's possible that their ASCII-EBCDIC conversion was the root problem, but it's hard to imagine that they wouldn't have used a standard library for that. ... They have standard libraries on mainframes, right?

    The replies back from that backend were always in upper case, too. I've seen the admins' configuration console for the thing, and everything there is also upper case.

    I'm pretty sure lower case is a modern invention, and the backend just didn't have flexibility in its architecture to add such a newfangled thing.



  • @Cassidy said:

    Presuming that the data is stored in a VARCHAR field and the case will be preserved... is the data actually captured in the correct case, or does it hit toUpperCase() before being stored in the DB?

    If someone's entering it all in caps, then that's how it should be displayed. If someone's app is swapping case mid-way, then it should be them that undoes their damage case changes.

     

    Based on the data I've seen during testing, I think what we have is whatever the user (or call center agent) entered.  I've seen John Smith, JOHN SMITH,  and JOHNSMITH.  The last one I suspect is more that somebody's routine is concatenating the first and last name, because it's only occasionally and oddly enough when the business folks complain, the name is magically fixed.  There's no way a program can know where to put the space unless it was concatenating two fields together to begin with.

    Good point about capitalizing names!  I hadn't thought of issues like McDonald. I do agree that whatever the user types in, should be what we store and eventually output.  Aside from names in an email, the other side of the same issue (that I sort of mushed together in my OP) is that my dev lead has case sensitive XML data input requirements because he's too lazy to use a case function.  For example, if the email template contains a variable $[[FIRST_NAME]] and the calling system sends over this name/value pair:

    <name>First_Name</name>

    <value>Joe Blow</value>

    Apparently it has trouble locating the first name variable so it can replace it with the value.  Try being the business analyst who gets to explain this to fairly technically-saavy business folks and PMs'.  There's some tongue-biting involved.

     



  • @jetcitywoman said:

    my dev lead has case sensitive XML data input requirements because he's too lazy to use a case function.
     

    There's one of your problems there. Or rather, there's the source of one of your issues.

    Alternatively, you could sell it as:

    @jetcitywoman said:

    "my dev lead has case sensitive XML data
    input requirements because he..."

    • ... doesn't write robust code
    • ... doesn't understand how to sanitise/translate/escape
    • ... isn't a good enough coder to consider how to deal with specific types of data  
    • ... likes writing fragile code that barfs in a large percentage of cases
    • ... knows the quality of his code is unrelated to the pay he's getting
    ... etc



  •  Exactly!  And he's the dev LEAD.  Thus my pounding head.



  • @jetcitywoman said:

    And he's the dev LEAD.

    Get the lead out!



  • @jetcitywoman said:

    Thus my pounding head.
     

    Identified another issue: you should be pounding his.

    Preferably with a large wooden table, suitable for photographing images prior to scanning for website pages.

    That's two lots of consultancy. To where do I send the bill?



  • @Xyro said:

    I'm pretty sure lower case is a modern invention

    Define "modern". Computers from the 70s supported upper- and lower-case ASCII. The ASCII standard itself, including lowercase, was published in 1968.

     



  • @Zylon said:

    The ASCII standard itself, including lowercase, was published in 1968.
    Work started on the standard in 1960, which presumes it was in abundance some time before, thus requiring The Standard to start with. And the first edition was '63, next major revision in '67, last update in '86. What happened in '68?


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.