- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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."
Admin
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.
Admin
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!
Admin
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?
Admin
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.
Admin
Why wouldn't it? That makes perfect sense! It's optimized! Less functions! More faster!
Admin
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.
Admin
Admin
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.
Admin
Admin
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.
Admin
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."
Admin
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....
Admin
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.
Admin
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.
Admin
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.
Admin
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!
Admin
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
Admin
I thought the spell is "Viagria levitrosa"
Admin
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.
Admin
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).
Admin
Admin
hey! that happened where i work a couple years ago someone removed a DNS entry no one thought was needed and broke my code
Admin
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).
Admin
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.
Admin
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.
Admin
Admin
Dude, you're flaming a spambot.
Admin
Win!
Admin
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:
Determine whether the client has access to the internet or not.
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.
Admin
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.