- 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
The real WTF is that he was using the test data in the test database on the testing server that is used for development work by many different groups of developers for the company - and he was bitching about inconsistent data that is all phony anyway, and includes bogus info to test the response of the software to potential errors. And why would a US programmer give a shit about Australia? It is just one more insignificant little country we had to bail out in the 1940s. We didn't get to be the world's only superpower by using metric numbers or liters or any of that other P.C. bullshit - and what has Austraulia got that we would want? Sheep? Not much mutton served here...
Admin
Made my day :)
Admin
in Chareths defence, ACT, NSW and QLD are states. in Australia. ACT = Australian Capital Territory NSW = New South Wales QLD = Queensland
as to why they would be needed in a US only(?) application, i cannot tell.
captha: praesent. thaenk you.
Admin
The real WTF is this competent techy boss.
Admin
Nope. Mine has 5: CARMS
I hate web forms that assume you live in the USA ...
I don't think he did anything wrong, I thought the point of the story was that the boss obviously had a sense of humour.
Admin
That's the official rate issued by the government of Zimbabwe. If you're willing to trade US dollars for Zimbabwean dollars at that rate, Robert Mugabe will be absolutely delighted to hear from you. The market rate is something like 14,000 Zimbabwean dollars to the US dollar. Although that was several hours ago.
http://en.wikipedia.org/wiki/Zimbabwean_dollar#Third_dollar_2
Admin
Chareth and Yuriyj are just a little confused since they had to learn SQL in 3 days when their outsourced helpdesk company was converted to an outsourced database programming firm.
Amirite?
Admin
Nice one. I keep getting calls (in the UK) from some Russian software house 'We write ebXML adapter. Fifteen thousand American dollar' in a broad Russki accent. Scary.
Admin
Silly boss. The clever developer was merely preparing for the eventual inclusion of CAN and MEX into the United States.
Admin
Geez, so much bull excrement. It's amazing how many people think they know everything about databases because they own a pirated copy of MS Access (do you want Access to add an extraneous unnecessary numeric column to you table?).
I think practical use of databases must be the worst understood area of development. I am not surprised by this, because when I did a Master in Computer Science the database course was taught by a Mathematician who specialised in Artificial Intelligence. He actually spent the entire first semester of the year teaching himself databases so he knew what he was teaching us. I came into the course off the back of two year's commercial experience as a database apps developer, and some of the stuff he taught us was either ten years out of date, or just plain wrong.
The project I've just started working on used to stored up to 11 records of null values in a 28 field table just because the last developer wanted to be able to retrieve 12 records for each key combination. Our data analysts had to deliberately pad the data before passing it to him. Madness.
Admin
Admin
Admin
(oh, and for the sarcasm-impaired: </sårcæsm>)
Admin
Admin
The real WTF is that they're building an e-commerce application that will immediately break if it encounters customers who aren't in the United States. Double WTF for beating up on the guy who noticed this and posting it to Daily WTF as if they were clever or something.
But, y'know - drill baby drill, or something.
Admin
Admin
So the axiomatic belief, "We're only going to handle US state codes" is going to make the existing legacy data (Australian states?) and its 3 character codes go away?
It's great to be right, but only when you communicated this to your users well before they started running the business on the basis of the "wrong" behaviours.
Admin
A competant boss who isn't willing to play stupid games with inexperienced staff. That's a WTF in itself. I'd love to work for this guy, but then I'd be working with Chareth and that sounds like it would get really tedious really quickly. I can foresee the conversations now: "But we can't represent the total number of open orders with an Int32; what if someone makes three billion orders?"
Admin
Lucky for Yuriy, if they ever planned on doing business with Canada, we succumbed to US stupidity years ago and brought our four/three letter province abbreviations down to two. Which meant rather than useful names like "PEI", "Nfld", "NWT" and "Que", we have "PE", "NL/NF/T-N", "NT" and "QC/PQ". Yay.
Admin
Yup. And if you die in Canada, you die in the real world.
Admin
You people make my head hurt.
It's a SP to calcuate US State Sales Tax. Read the story.
If it's an international order, Why would you call a SP to calculate US State Sales Tax? How much feature creep should you add to a SP Spec'd to calculate US State Sales Tax? Maybe it should calculate export duty, VAT, custom fees? It should probably also calculate shipping, estimate the delivery time, parse XML, recommend other products the customer may be interested in, serve up online ads, and be able to send and receive e-mail as well. What if the US State Sales Tax for Leningrad changes over a 3 day weekend- Do you want to come into the officer to change it, or send a quick e-mail from your blackberry and have the SP update itself while you're still poolside? It certainly shouldn't not be called on International Orders, or return either an appropiately handled error or a zero (Depending on spec) when called for an international order.
Why are your praising him for being able to calculate the US State Sales Tax for Lebenon, but not slamming him for the Zip Code? If Chareth is right on #1, he's wrong on #2.
No wonder this site hasn't run out of stories yet- Nobody reads the spec, and everyone wants to create a single SP that does everything.
Admin
By the way: "Execdrin headache #4" -- freudian slip, or deliberate wordplay on the source of your headache (executives)?
Admin
À partir de maintenant, j'essaierai de faire ce que tu as proposé.
You are right.
From now on, I will try to do what you sugested.
Admin
"taddle-tail"
It's tattle-tale. "Tale" meaning story, and "tattle" meaning to gossip or just generally ramble on.
Admin
If you're trying to use individual fields for address parts like city, state, zip, AT ALL, you run the risk of being tempted to shoehorn international addresses into the "Name / Street Address 1 / Street Address 2 / City, State Postal-code" format even when it may be inappropriate.
Admin
mmmm... Tequila...
Admin
NVARCHAR. Try asking yourself why you think you need to treat the city, state, zip separately.
Admin
Admin
Why do you need the state field being used for this purpose to be used as an address part?
Admin
Cute story.
Admin
"1) The US doesn’t have any three character states and we’re not planning on annexing any states anytime soon. "
Someone seems to be missing the point.
If the existing data already has 3-character identifiers, then, even though the field is called "state" it contains more than just US States.
Fail. (plus a snotty answer).
Admin
Unbelievable! Chareth is a complete moron....
Here is probably how Yuriy's response email went: 1.)Are you kidding me?
2.)Wow, thanks for the wasted time verifying a simple matter
3.)Are you F#@king kidding me?
4.)You're Fired.
Regards, Yuriy
Admin
The REAL WTF, is that this post is ambiguous about what the real WTF is!
Admin
My boss writes emails just like that, and every time he does it, I want to destroy worlds.
Admin
IN = Indiana
Admin
Admin
Gardez-le sous votre chapeau, s'il vous plaît.
Admin
As far as storing information on subnational entities, there is already an ISO standard, 3166-2. For the USA, it uses the postal abbreviations. (Canadian provincial abbreviations are also two letters, and do not clash with US ones; Mexican state codes are variable length like Australian ones--only more so.)
Admin
There's also the annoying little detail that the problem can't be solved precisely! (Zip code is not sufficient to compute the tax rate. For example, zip code 37015 includes the city of Ashland City, rate 9.75%, but also unincorporated areas of Cheatham County, rate 9.25%.)
Heck, at one time, given an address on Morris Hill Road in 37421, you still didn't have enough information without the actual number--if it was odd, you had to charge 9.75, but if it was even, 9.25 was the rate!
Admin
And what if you expand into a country which has state abbreviations that conflict with American ones?
There are extremely few truly natural keys. EXTREMELY FEW. Not even social security numbers are unique.
This is why it is best to avoid natural keys no matter how unique something appears to be. You are setting yourself up for incredible headaches in the future when you could simply use a surrogate key now and eliminate that issue right at the start.
Surrogate ints are also going to be much faster in comparisons than comparing strings of any length greater than 1.
Your code is not easier to maintain by using natural keys - it's just quicker to do right now. But you'll pay for it in the long run.
Admin
If you try to feed one more foreign country into my Compute_US_SALES_TAX module, you're fired.
Admin
it would have been better if he used bcc
Admin
Exchange rate is 1 U.S. dollar = 45 Philippine pesos I think.
Admin
So, you need to know what the salestax is and this stored procedure calculates it. How are you going to know which states need to be taxed? Perhaps that information is in the database, rather than hard coded in to the application.
Admin
I read this article a few time along with a bunch of the comments, and is it me or is the tone immediately against Chareth. Next time add more context to the article. For all I know, the guy could be considered "Junior", because he is the new guy, which in my opinion is wrong.
TRWTF is the fact that we are judging him, with no understanding of why his code got rejected. Was his code really bad, or did it not conform to standards, or is he trying to bring modern practices into a hack shop, and Yuri doesn't understand them. Perhaps the requirement specifications are incomplete or fucked.
Obviously there is more to this story than the article suggest. Bringing your boss into a disagreement as a mediator, to prevent a pissing match shows a degree of professionalism. TRWTF2 is the asinine way that his boss responded to him. I suggest Chareth try to find a better company, were he has another chance to find a boss, that isn't such a dick.
Admin
This is either a horrible post or a great one. It's so ambiguous, I can see it both ways. C is out there trying to prove himself, Y is out there doing his thing, and the Boss just wants what works to be done, not to worry so much for tomorrow.
From both y & c perspective the other is the dumb jerk.
The boss seems to be the most competent, it's a US state tax function, then it only needs to know about states (the name of the function dictates the programmatic contract). If you feed it non state codes its behaviour is and should be undefined. Garbage in Garbage out. Actually, in fact, limiting it to CHAR(2) greatly reduces the amount of possible invalid values.
Admin
The only thing that seems to be in Chareth's favor is that there was existing data in the state table that was more than two characters long. The NSW seems like it might stand for "New South Wales" and the QSD for "Queensland" that is, for states in Australia. Perhaps this was an application that was international and really did need a state field that was more than two characters. I don't know. But the data are what the data are...
Admin
It's a shame nobody in the preceding 150-odd posts managed to work out that NSW stands for "New South Wales," rather than, say, "No Such Waldo." Data is, by the way, the plural of a Greek neuter noun, and thus (Grammar Nazi) takes the singular. IHFTFY. Works better that way in English, too.
QLD stands for "Quod Licet Demonstrandum," which I believe is a captcha in these parts.
Now. Attention span deficit ... plain ignorance ... tedium ... wanna pick a card? Then we can play.
Admin
Not that this all isn't pedantic but...
Why doesn't the PHB address "existing data" which has examples clearly outside the US - e.g. QueensLanD?
Again the PHB doesn't address the issue which is that it's a good idea to match field formats in (wtf is) AX. Yes, ha ha they're big numbers but is it really harmless if the formats don't match?
Admin
First, there are more natural keys than you think. Second, the ones that do exist are extraordinarily useful because they are universal. It would be stupid for example not to use the ISO code for storing currencies. There is no valid reason against using the State abbreviation. A surrogate key does not help you when storing State data. Instead, in increases the odds of creating crap data. To wit, if the developer does not make the abbreviation column in States table Non-null and Unique, you will create headaches for yourself when you query the data. Instead you will get developers that query on "magic" values like "Select... From ...Where StateId = 5".
Surrogate keys are not always faster for comparison. For example, suppose I have an addresses tables with a million rows. If I use the State abbreviations, then I need no other join to find all people in CA. However, in your scenario, I must use a join or use magic values. Even worse is if someone changes the value of Id #5 to be CA instead of VA.
When there is a rock solid natural key like State abbreviation, you are always better off using it.