• Mark (unregistered) in reply to Anon

    Ah, the programmers were following rule #3 from "How to write unmaintainable code":

    "Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database."

  • Derp (unregistered) in reply to hatterson
    hatterson:
    Derp:
    campkev:
    Andy Goth:
    Why is this autodetected and not simply a configuration variable in the same way that HQ_SERVER_NAME is?
    Because if it was, it wouldn't be on this site.

    No, because HQ_SERVER_NAME is a CONSTANT that doesn't change from installation to installation, but the need to fire up a modem does.

    Uhhh, what?

    Why would having SITE_CONNECTION_TYPE as a configuration variable not be a good thing for something that changes with each site?

    Uhhh, what?

    You must be one of the IT guys from yesterday's article trying to create job security. Or who do you see setting that up at each location? u gonna get a wizard to do it? Just say gloves, hatterson.

    And maybe stop capitalizing all your variables, it's rude to shout.

  • Herby (unregistered)

    Of course there is a simple thing to do: Use a "well known" site like "www.yahoo.com" for HQ_SERVER_NAME. It really doesn't matter what external thing they look up, as long as it exists.

    Yes, "www.yahoo.com" may be a bad example in these turbulent times, but you get the idea. Maybe "www.thedailywtf.com" would be better!

  • (cs) in reply to Downfall
    Downfall:
    How many WTFs spring from trying to 'optimize' things already working fine?

    Equally, how many WTF's are entirely caused by that mindset? Have you noticed the WTF is there already and revealed by optimizing, not created by it?

  • Scott (unregistered)

    Everyone here seams to be under the assumption that by removing the dns entry, the query would now use return a server not found.

    But if that entry was a sub-domain and there is a valid *.domain.com entry, then the query would return a valid ip address, and the ping would succeed, causing the code to throw an exception.

  • evilspoons (unregistered) in reply to Mark
    Mark:
    Ah, the programmers were following rule #3 from "How to write unmaintainable code":

    "Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database."

    Why wouldn't it? That makes perfect sense! It's optimized! Less functions! More faster!

  • Downfall (unregistered) in reply to tin
    tin:
    Downfall:
    How many WTFs spring from trying to 'optimize' things already working fine?

    Equally, how many WTF's are entirely caused by that mindset? Have you noticed the WTF is there already and revealed by optimizing, not created by it?

    If it's not important enough to test properly, it's not important enough to fix. Had they left it alone or fixed it properly, there would have been no problem. It's this half-ass approach to fixing problems that's the worst of both worlds. At best, a trivial problem is removed. At worst, unforeseen problems are introduced and lots of money is wasted. This one is somewhere in between-- had the problem been left alone, it would have been fine. To reiterate: Fixing something that's working with a half-ass methodology is significantly worse than doing nothing.

  • Mark Draughn (unregistered) in reply to hatterson
    hatterson:
    Anonymous Coward:
    You laugh, but I do most of my development in a production environment...

    BTW, it pays way too much for me to complain.

    If it pays you too much to complain then the company must have some spare money sitting aside to rig up a simple test environment. Sure maybe you won't get a clone of the production environment but even a $500 crappy eMachines desktop is better than developing in production.
    If you make changes in production, you risk breaking things. If you make changes in development, it takes longer to respond to change requests. What you do depends on which is worse.

  • Casey (unregistered)

    Years ago at my old company, CSC whom we contracted to run our mainfame was cleaning up accounts that never logged in. One of them was G.E. Neric, aka "generic" which was the account name all our batch ran under.

  • Cheong (unregistered) in reply to biziclop
    biziclop:
    It doesn't have to though, does it? They don't really open a connection to anything but their DNS server. Which is what they should've done in the first place.
    It activates modem when ConnectionType is Dialup, so when finished uploading data, just check the connection type and you'll see whether you need to call the function to hook off.
  • Gollum (unregistered)

    Great, I just love utility functions that have side effects and don't indicate that in their name.

    I know one big British consulting company that prefers to do everything via hosts files. The fact that they have a centralized network admin team who would take at least two days to do anything at all is only a small part of it.

  • jimicus (unregistered) in reply to Gollum
    Gollum:
    I know one big British consulting company that prefers to do everything via hosts files. The fact that they have a centralized network admin team who would take at least two days to do anything at all is only a small part of it.

    Sweet Jesus. Mind you, an employer of mine used to do the same thing.

    I was never quite sure how to word the email explaining that messing around with hosts files was no longer necessary nor supported. Eventually I settled with "I've done some research and found that DNS was rolled out in 1984 and it's no longer the early 1980's."

  • grg (unregistered)

    so let's count the WTF's in here:

    (1) Function name does not reflect what it does. (2) Checking the wrong thing to determine connectivity. (3) Assuming a failure to ping means no connection. (4) Throwing away an important error message. (5) Comparing error message against fixed string. (6) "Dialing up" but not checking that for success. (7) Assuming UDP services like DNS and ping are always definitive.

    So many problems, so little time....

  • Orbstart (unregistered) in reply to Asiago Chow
    Asiago Chow:
    JamesQMurphy:
    Right, like the InetIsOffline API.

    I've never needed to use that API, but... googling around shows it returns false negatives. Looks like it only checks the status of designated internet connections instead of checking for internet connectivity. Is that true? If so they may have started there and switched to DNS lookup testing because it better fits their problem. They don't care whether an "internet connection" is "connected" per the OS, they care whether they are able to talk to the 'net.

    OT: The real WTF is that the function InetIsOffline() is inversed so it returns TRUE when the outside net cannot be contacted. Makes for good readability.

  • Orbstart (unregistered) in reply to Herby
    Herby:
    Of course there is a simple thing to do: Use a "well known" site like "www.yahoo.com" for HQ_SERVER_NAME. It really doesn't matter what external thing they look up, as long as it exists.

    Yes, "www.yahoo.com" may be a bad example in these turbulent times, but you get the idea. Maybe "www.thedailywtf.com" would be better!

    And then you're adding a deeply embedded dependency on a 3rd party. Sure, it is very very unlikely that a Google host would disappear, but then when are we not in "turbulent times"? What if they decided to block pings or restrict the ICMP accept range but only on a Tuesday, now you have a deeper WTF.

  • Wyrd (unregistered)

    One good way to ensure that you'll have to do something over again is to do it the wrong way the first time.

    -- Furry cows moo and decompress.

  • (cs) in reply to Orbstart
    Orbstart:
    Asiago Chow:
    JamesQMurphy:
    Right, like the InetIsOffline API.

    I've never needed to use that API, but... googling around shows it returns false negatives. Looks like it only checks the status of designated internet connections instead of checking for internet connectivity. Is that true? If so they may have started there and switched to DNS lookup testing because it better fits their problem. They don't care whether an "internet connection" is "connected" per the OS, they care whether they are able to talk to the 'net.

    OT: The real WTF is that the function InetIsOffline() is inversed so it returns TRUE when the outside net cannot be contacted. Makes for good readability.

    Negative function names are in my top 10 code WTFs.

    You end up with hideous double-negative statements that make baby Jesus cry:

    if (!InetIsOffline()) { // Send Data } ngggh!

  • Rev. Creflo Baller (unregistered)

    Many years of toiling in retail and dealing specifically with store polling have taught me that Curtis's first instinct (maybe all the stores were closed) was a good one. It's inevitable that someone is going to report an outage the day after a holiday when lots of sales data is missing. It is at once gratifying and a bit nauseating to be the guy who walks in on a panicked conversation between angry executives and points out that yesterday was Easter and we weren't expecting any stores to poll.

    TRWTF is how many posters don't get a) falling back to dialup if broadband is not available and b) the "function" in the article is just pseudocode and may have only a cursory relationship to the actual specimen.

    Really, guys, having a fallback plan in case of a cut connection is SOP when dealing with hundreds or thousands of remote locations that have no IT staff. No, you shouldn't generally put something like "connection type" as a configurable--you want to be able to redistribute hardware without having to fool around with 8000 settings that the in-store staff don't understand. If the failback/failup is done right you should never have to touch it.

    There is one and only one WTF here and that is to rely on internal DNS as an indicator of connectivity.

    /CAPTCHA: "genitus" -- a spell from Hairy Bottom and the Sorcerer's Bone that fixes ED

  • (cs) in reply to Rev. Creflo Baller
    Rev. Creflo Baller:

    /CAPTCHA: "genitus" -- a spell from Hairy Bottom and the Sorcerer's Bone that fixes ED

    I thought the spell is "Viagria levitrosa"

  • Joao Marcus (unregistered)
    Yeah, pretty much. If something is wrong but sitting there and not hurting anything, leave it be. How many WTFs spring from trying to 'optimize' things already working fine?

    How many WTFs spring from trying to work around things that are buggy but supposedly working fine, turning all the code into a giant mess because everyone is working around those "tiny bugs" and nobody is willing to fix them? Then, a couple of years later, someone detects a serious flaw caused by that "tiny" bug. And now it's too late to do anything about it. All your code evolved around the bug.

  • Worf (unregistered) in reply to Herby
    Herby:
    Of course there is a simple thing to do: Use a "well known" site like "www.yahoo.com" for HQ_SERVER_NAME. It really doesn't matter what external thing they look up, as long as it exists.

    Yes, "www.yahoo.com" may be a bad example in these turbulent times, but you get the idea. Maybe "www.thedailywtf.com" would be better!

    Better yet, why not the company's main web site? If it fails to exist, well, it doesn't matter if the stores don't post. Probably a good thing, too (until that domain is snatched up by a porn site).

  • (cs) in reply to Madt M.
    Madt M.:
    I have a restaurant that uses dial-up: - At 2400 baud credit card transactions take only seconds
    If by "only" you mean "about 30", as is my experience, it's frustrating to the customers. Most people are used to authorization taking less than five seconds over broadband. Initializing a modem, dialing, and negotiating (even at 2400 bps) takes at least 15 seconds all by itself. I suppose that if it's not a restaurant where the customer pays on the way out, it doesn't matter so much.
  • dude (unregistered)

    hey! that happened where i work a couple years ago someone removed a DNS entry no one thought was needed and broke my code

  • A.C. (unregistered) in reply to hatterson
    hatterson:
    If I'm reading it correctly wouldn't this just cause all sites to act as if they're on dial-up.

    As far as I can tell, you're right. But I'm guessing these sites that were on broadband didn't have the modem cable plugged in (or didn't have a modem installed).

  • Asiago Chow (unregistered) in reply to Mr B
    Mr B:
    Negative function names are in my top 10 code WTFs.

    You end up with hideous double-negative statements that make baby Jesus cry:

    if (!InetIsOffline()) { // Send Data } ngggh!

    That might just indicate you are using the function incorrectly.

    e.g. it would be better to say:

    if (InetIsOffline()) { // connect }

    // send

    That way your code only takes the branch if there is something special to do.

  • John (unregistered) in reply to Downfall
    Downfall:
    If something is wrong but sitting there and not hurting anything, leave it be. How many WTFs spring from trying to 'optimize' things already working fine?

    I don't agree. If you just let wrongness upon wrongness exist in the code, you eventually end up with something like CASTLE and guys like Tyson who are the only ones able to maintain the code, since they -know- what is junk and what isn't (and to be honest, even they can't tell anymore after some time).

    We've all seen this happening, systems get build very fast and there's never time to remove test code or code that is replaced in later iterations. There's also never time to rewrite all those "quick-prototypes-that-we'll-replace-when-we-have-the-requirements-right". Eventually, typically sooner than later, development hits a wall and you're unable to innovate anymore. You sprinted ahead of the pack, but your competitors catch up with you laughing, leaving you to bite their dust.

  • Compliance Sheep (unregistered)
    Warhammer Gold:
    ...wow power leveling Grinding Guide Some people consider grinding the fastest way to level...

    [snip]6 paragraphs of stupid SPAM[/snip]

    Dude, you're posting in the wrong forum... anyone here that plays WoW probably already has a level 70 Knight Elf... go post in allaboutbrittney.net where all the 1337 12yo's hang out >:| ...jackass

  • aliquot (unregistered) in reply to Compliance Sheep

    Dude, you're flaming a spambot.

  • Sum egghead (unregistered) in reply to aliquot
    aliquot:
    Dude, you're flaming a spambot.

    Win!

  • Robin Goodfellow (unregistered)

    A lot of people seem to have trouble understanding this code so I'll take a shot at explaining.

    The intent of the code is two fold:

    1. Determine whether the client has access to the internet or not.

    2. If the client does not have access to the internet, use the modem.

    The WTF here is that the test for whether the client had access to the internet was to ping a non existent host, but a host that would resolve in DNS. If the ping command timed out, then this function would decide that the client was connected to the internet. If the ping command couldn't find the host at all, then this function would decide it wasn't connected to the internet at all.

    When the old, unused DNS entries were removed that forced the function to always believe it was disconnected and to try to use the modem. Which only worked for those locations with functioning modems installed.

  • sutech (unregistered)

    Reminds me of one solution we came up with.

    We had no indicator if our monitoring system was properly monitoring. If we got no alerts then we assumed that every monitored machine is working fine. Well, there was some issue that caused that from time to time we didn't get any alert because of network issue. So we set up a DNS entry unreachable.country.company.com to check if it's working. If we got no alert from unreachable (which was just an unassigned IP) then we knew that something is wrong.

Leave a comment on “Scratch One Inevitability”

Log In or post as a guest

Replying to comment #:

« Return to Article