Well, it *is* the Answer to Life, the Universe, and Everything...



  • So we currently have something logging transactions in a central database, and one of the columns currently being saved is a status with values like this:

    “Success”, “Invalid”, “Undeliverable”, ...

    These are digested from a continuum of various conditions, exceptions, and the like. 

    In one certain circumstance, there’s a piece of data that’s coming back when it otherwise looks like a “Success” whereby the endpoint we’re talking with is actually indicating that something was unavailable.  From the the developers' perspective, this should cause that status to be “Unavailable” instead.  Problem solved!

    Except that our newish database expert doesn’t work that way.  He’s been arguing for a couple weeks that he must, must, MUST have the exact code that we’re receiving, as we should never be doing that kind of translation above in code!

    After lots of arguing at various levels, I hear we’re now going to be populating that database with the following:

    “Success”, “Invalid”, “Undeliverable”, …, “42”

    Problem solved!



  • Had a similar conversation with a database expert who had written some java code. He had made the "toString" method of a fairly complicated object return the codes (e.g. 1: Raw, 2: Processed; 1: Monthly, 2: Year To Date Cumulative; 1: Actual, 2: Budget: etc.) as a string of numbers: 1121132 or whatever. I took the opportunity at one point of converting these to understandable strings, so the object would be rendered in the log as "Raw, Monthly, Budget, ..." etc. You should have heard him create a fuss. "But nobody will be able to understand it! Everyone knows that 1 means Raw and 2 means Processed, and if they don't they need to learn it!"

    I don't work there any more. He's been busted back down to javanaut, inheriting back all the code that I originally inherited from him in the first place. He can go and change it all back again now to whatever he wants and I will never ever have to care about it again. Life is sweet.



  • You would be surprised how many people love their acronyms and codes forced on them in the era of mainframe programming. Now that the memory and space limitations are negligible we have to explain to them that it actually can be better to use real words and phrases since they don't have to be looked up every time.



  • @jpolonsk said:

    it actually can be better to use real words and phrases since they don't have to be looked up every time.

    Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); or b) you are sending a humungous DB across a network or by FTP to a remote site, which in some cases can add several GB of data, thus quite a bit of extra time. Horses for courses, and all that. :)



  • @Cad Delworth said:

    @jpolonsk said:
    it actually can be better to use real words and phrases since they don't have to be looked up every time.
    Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); or b) you are sending a humungous DB across a network or by FTP to a remote site, which in some cases can add several GB of data, thus quite a bit of extra time. Horses for courses, and all that. :)
     

    More importantly, it allows for easy internationalisation.



  • @RogerWilco said:

    @Cad Delworth said:
    @jpolonsk said:
    it actually can be better to use real words and phrases since they don't have to be looked up every time.
    Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); [...]
    More importantly, it allows for easy internationalisation.
    Are you saying it's easier to internationalize "23" than it is "Foo"?

    A mapping from code to description doesn't care if the codes are symbolic or numeric, and supporting internationalization doesn't imply that an internal protocol or identifier has to be numeric instead of symbolic.



  •  @Thuktun said:

    @RogerWilco said:

    @Cad Delworth said:
    @jpolonsk said:
    it actually can be better to use real words and phrases since they don't have to be looked up every time.
    Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); [...]
    More importantly, it allows for easy internationalisation.
    Are you saying it's easier to internationalize "23" than it is "Foo"?

    A mapping from code to description doesn't care if the codes are symbolic or numeric, and supporting internationalization doesn't imply that an internal protocol or identifier has to be numeric instead of symbolic.

    The problem with translating short strings is the double meaning of some words. An extreme case: How do you translate "Bin Oct Hex Dec"? That's easy, but what if "bin" stands for "binary" in one case and "trash" in another?


  • @Kiss me I'm Polish said:

     @Thuktun said:

    @RogerWilco said:

    @Cad Delworth said:
    @jpolonsk said:
    it actually can be better to use real words and phrases since they don't have to be looked up every time.
    Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); [...]
    More importantly, it allows for easy internationalisation.
    Are you saying it's easier to internationalize "23" than it is "Foo"?

    A mapping from code to description doesn't care if the codes are symbolic or numeric, and supporting internationalization doesn't imply that an internal protocol or identifier has to be numeric instead of symbolic.

    The problem with translating short strings is the double meaning of some words. An extreme case: How do you translate "Bin Oct Hex Dec"? That's easy, but what if "bin" stands for "binary" in one case and "trash" in another?
    How is that different than translating "23 24 25 26" if "23" stands for "binary" in one case and "trash" in another?


  • @Jaime said:

    How is that different than translating "23 24 25 26" if "23" stands for "binary" in one case and "trash" in another?

    Because you then have 23=bin and 24=bin



  • @XIU said:

    @Jaime said:
    How is that different than translating "23 24 25 26" if "23" stands for "binary" in one case and "trash" in another?

    Because you then have 23=bin and 24=bin

    Reminds me of a Barenaked Ladies song: Crazy ABCs. (Apologies for crappy lyrics site.)



  • @XIU said:

    Because you then have 23=bin and 24=bin

    But you can also do that with alphanumeric identifiers e.g. BinAsInBinary=bin and BinAsInTrash=bin.

    I think

    translate("BinAsInBinary") + translate("OctAsInOctal") + translate("DecAsInDecimal") + translate("HexAsInHexadecimal")
    is a little more easily understandable than
    translate(23) + translate(24) + translate(25) + translate(26)


  • Discourse touched me in a no-no place


Log in to reply