• JackD (unregistered)

    His boss will be regretting that reply when inflation jumps so high that gass is 85 trillion dollars a gallon!

  • (cs)

    Cardinal rule II: Don't CC the bosses on this type of dialogue.

  • Rincewind (unregistered)

    Doesn't "State" refer to status? I.E. Act = Active vice one of the United States. And doesn't this indicate the bosses boss doesn't have a clue?

  • Dude (unregistered) in reply to Rincewind

    He shoud send that mail to lead developer or someone higher who woud be smart enough.

  • Survey User 2338 (unregistered)

    Ahh...to once again have a boss who knows when to call bullsh*t. Those were good days.

  • Zap Brannigan (unregistered) in reply to Rincewind
    Rincewind:
    Doesn't "State" refer to status? I.E. Act = Active vice one of the United States. And doesn't this indicate the bosses boss doesn't have a clue?
    I see the confusion, this like our ERP. We store state abbreviation and status in the same column. It keeps our database schema simple.
  • cpt (unregistered)

    The three letter codes are Australian states (Australian Capital Territory, New South Wales, QueensLanD.

  • (cs)
    ...like another dagger made of salt and lemon juice...
    When life gives you salt and lemon juice, add tequila.
  • (cs)
    Yuriy's boss:
    if we get an order with a subtotal of octillion dollars then we’ll just make sure to discount it by sextillion dollars thereby getting us down to our precision number of 922 trillion dollars

    Buzzer

    Sorry, you lose... to get an order of octillion dollars down to 922 trillion dollars, you need to discount it by (almost) an octillion dollars, not merely by a sextillion dollars.

  • occasional reader (unregistered)

    I've seen stuff like this before - people realising that the world doesn't rotate around the USA - where the 'state' column in addresses are relaxed to include provinces of Canada and abbreviated regions and counties of other countries.

    Maybe the junior developer might have been correct in this - the tax calculation might have been flexible to be used for countries other than the US?

    I'm sure the senior developer is correct in that the US isn't planning to annex another state quite this minute :-)

  • Bryan Kowalchuk (unregistered)

    They are both wrong. All money calculations in SQL Server should be done using the money datatypes. These are specifically designed for guess what? Money! They are special fixed precision (4 decimal) place variables that do not loose precision as the number becomes larger. By using the money dataypes, you eliminate many of rounding and precision problems.

  • (cs)

    I like the boss - I want to work for him!

  • (cs)

    I can't believe nobody has mentioned it yet: The problem here seems to be that Chareth is one of those primadonna developers who think they know better than everybody else in the company, including (especially) those who have been there for many years. Now, I've worked for my fair share of morons who couldn't code their way out of a wet paper bag despite being "VP of Software Development" or some such grandiose title, but in this story the WTF is clearly with a junior programmer who thinks that he's hot stuff, even when he's not.

  • Satipo (unregistered)

    Bryan that might be fine except not everyone in the world uses Microshaft abominations.

  • TallGuy (unregistered) in reply to occasional reader
    occasional reader:
    I've seen stuff like this before - people realising that the world doesn't rotate around the USA - where the 'state' column in addresses are relaxed to include provinces of Canada and abbreviated regions and counties of other countries.

    Maybe the junior developer might have been correct in this - the tax calculation might have been flexible to be used for countries other than the US?

    I'm sure the senior developer is correct in that the US isn't planning to annex another state quite this minute :-)

    Wait...what's Canada, then? A foreign country?!

  • I have no name. (unregistered) in reply to Rincewind
    Rincewind:
    Doesn't "State" refer to status? I.E. Act = Active vice one of the United States. And doesn't this indicate the bosses boss doesn't have a clue?

    Those are Australian states.

  • (cs) in reply to Charles400
    Yuriy:
    We won’t be changing any data types.

    Depending on the DBMS, defining such enormous datatypes can take up significant space (at least on numerics). Based on his comments of insane scale, it might be worth it.

    And, to Chareth's point, how does he know the corp won't expand into Australia or Mexico (do they have abbreviations for their states?)????

  • frustrati (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    I can't believe nobody has mentioned it yet: The problem here seems to be that Chareth is one of those primadonna developers who think they know better than everybody else in the company, including (especially) those who have been there for many years. Now, I've worked for my fair share of morons who couldn't code their way out of a wet paper bag despite being "VP of Software Development" or some such grandiose title, but in this story the WTF is clearly with a junior programmer who thinks that he's hot stuff, even when he's not.
    Wow, you can read! Cool!
  • (cs) in reply to occasional reader
    occasional reader:
    I've seen stuff like this before - people realising that the world doesn't rotate around the USA - where the 'state' column in addresses are relaxed to include provinces of Canada and abbreviated regions and counties of other countries.

    Canadian Provinces use two letter abbreviations too (AlBerta, British Columbia, QuebeC...). They and the US also share the North American (telephone)Numbering Plan. I guess Mexico diverged from NANP as they don't have the same system but it appears they did at one point (hence the name and similarity).

    BTW, Japan has the most wordy addresses (when spelled with Roman letters, of course).

  • Bush (unregistered) in reply to occasional reader
    occasional reader:
    I'm sure the senior developer is correct in that the US isn't planning to annex another state quite this minute :-)

    What about IQ and IN?

  • Former Junior Programmer (unregistered) in reply to TallGuy
    TallGuy:
    Wait...what's Canada, then? A foreign country?!

    The 51st state.

  • (cs) in reply to Pecos Bill
    Pecos Bill:
    And, to Chareth's point, how does he know the corp won't expand into Australia or Mexico (do they have abbreviations for their states?)????

    Then they would have to deal with other countries' state/provincial tax laws, along with their (if any) federal tax laws. 50 state & federal tax laws is enough to deal with! Damnit Jim he's just a junior developer!

  • frustrati (unregistered) in reply to TallGuy
    TallGuy:
    occasional reader:
    I've seen stuff like this before - people realising that the world doesn't rotate around the USA - where the 'state' column in addresses are relaxed to include provinces of Canada and abbreviated regions and counties of other countries.

    Maybe the junior developer might have been correct in this - the tax calculation might have been flexible to be used for countries other than the US?

    I'm sure the senior developer is correct in that the US isn't planning to annex another state quite this minute :-)

    Wait...what's Canada, then? A foreign country?!

    If you aren't located in Canada, yes.

    Exception is Quebec, from within which Canada is an oppressive federation that has wrongfully annexed the proud and sovereign state of Quebec.

    Oh, and for the record, Canada has perfectly good two-letter abbreviations for all of its 13 provinces and territories.

  • APH (unregistered)

    Actually, I think the Jr. Programmer may have had a point in his arguments. He didn't come up with these precisions out-of-the-blue, he was comparing this to existing objects in the database. I believe he was pointing out inconsistencies. Why would you make a State field 10 characters in one place and 2 in another? That is asking for trouble in my book!

  • (cs) in reply to cpt
    cpt:
    The three letter codes are Australian states (Australian Capital Territory, New South Wales, QueensLanD.
    A few years back, one of the projects I worked on had a "state" column in the db, and I noticed that it had way more than 50 distinct values in it. It was explained to me that since all US states were 2 letters, and that the business folks were now doing business internationally, that rather than change the db and everything that depended upon it, we'd just be assigning arbitrary 2 character combinations for each new region.

    What they didn't tell me about was the range of allowable characters that the auto-state-name-generation function was designed to use... all printable ASCII characters!

    It sounded reasonable until the auto-state-name-generation function eventually created new state codes like backslash-dot and dot-star, and then the value from the state column got parsed with a regex - it made for some interesting debugging sessions.

  • freakpants (unregistered) in reply to Charles400

    as far as I understand he tried to have the same precision in the application as in the database. whats so wrong about that??

  • ascagnel (unregistered)

    The US does have 3-letter states. If you're in the military, you use a special 3-letter state code in place of your actual location. The post office is equipped to handle this, and so should every website.

  • Zap Brannigan (unregistered) in reply to occasional reader
    occasional reader:
    I've seen stuff like this before - people realising that the world doesn't rotate around the USA - where the 'state' column in addresses are relaxed to include provinces of Canada and abbreviated regions and counties of other countries.

    Maybe the junior developer might have been correct in this - the tax calculation might have been flexible to be used for countries other than the US?

    I'm sure the senior developer is correct in that the US isn't planning to annex another state quite this minute :-)

    Possible new states:

    IQ - Iraq IR - Iran

  • frustrati (unregistered) in reply to Bush
    Bush:
    occasional reader:
    I'm sure the senior developer is correct in that the US isn't planning to annex another state quite this minute :-)

    What about IQ and IN?

    Don't forget AG.

  • (cs) in reply to Bush
    Bush:
    occasional reader:
    I'm sure the senior developer is correct in that the US isn't planning to annex another state quite this minute :-)

    What about IQ and IN?

    This is the US you're talking 'bout. We don't need no stinkin' IQ.

  • B (unregistered)

    The first critique sounds actually valid: some parts of the world use three-letter abbreviations for states, like Australia (Australian capital territory=ACT, New South Wales=NSW, Queensland = QLD). If the company has a record of dealings with clients in Australia, then it's reasonable to want a three-letter state.

    But yeah, the rest of it is stupid.

  • frustrati (unregistered) in reply to ascagnel
    ascagnel:
    The US does have 3-letter states. If you're in the military, you use a special 3-letter state code in place of your actual location. The post office is equipped to handle this, and so should every website.
    Yeah, but some of us prefer to normalise the data, so if it OK with you, we'll map your three-letter abbreviations to our internal two-letter versions.

    Btw, three-letter states? I have heard of four-letter states like Ohio and Iowa. Not heard of any three-letter states...

  • Peter (unregistered)

    I'd probably stand by him on the state portion, but I can see that the likelihood of any dollar amount larger than what would fit in a "money" datatype is very small. Still, his point on matching datatypes is semi-valid and could at least have been discussed prior to getting to this stage.

  • (cs) in reply to Bryan Kowalchuk
    Bryan Kowalchuk:
    They are both wrong. All money calculations in SQL Server should be done using the money datatype...
    There are more software houses than just Microsoft. Most DBMS have a money data-type. Surprisingly , MySQL & PostgreSQL don't. I guess they feel the numeric type is sufficient.
  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    I can't believe nobody has mentioned it yet: The problem here seems to be that Chareth is one of those primadonna developers who think they know better than everybody else in the company, including (especially) those who have been there for many years. Now, I've worked for my fair share of morons who couldn't code their way out of a wet paper bag despite being "VP of Software Development" or some such grandiose title, but in this story the WTF is clearly with a junior programmer who thinks that he's hot stuff, even when he's not.

    I have to agree with you on this. Seems like one of those losers that when he doesn't get his way he CC's somebody. I hate those fuckers. As if CCing my boss is gonna make things change in your favor. I hate the CC game.

    Things aren't always perfect, sometimes there will be some "waste" in the corporate world, you don't always get your way so get used to it, stop being a whiny bitch and deal. This guy acts as if the company is going to crumble because it uses a little extra space on the DB.

  • former military (unregistered) in reply to ascagnel

    No, the state code for military addresses is still two letters. For example, an address at Kunsan Air Base in Korea would have a "state" of AP and zip code of 96264.

    What you're thinking of is the "city", which in my example would be APO.

    But you are correct that websites need to accomodate for this. I had to contact customer support a few time while I was there because a company's website only listed the 50 states that they know of, plus DC in the drop down.

  • Peter (unregistered) in reply to frustrati
    frustrati:
    ascagnel:
    The US does have 3-letter states. If you're in the military, you use a special 3-letter state code in place of your actual location. The post office is equipped to handle this, and so should every website.
    Yeah, but some of us prefer to normalise the data, so if it OK with you, we'll map your three-letter abbreviations to our internal two-letter versions.

    Btw, three-letter states? I have heard of four-letter states like Ohio and Iowa. Not heard of any three-letter states...

    See comment from "snoofle" above. When you start going International, you have changes to make that get really hairy to map into a char(2) column. If you'll always be a US-only company, that's not a big deal, but once you step outside of the US, you're going to have some changes to make or deal with some really odd mappings.

  • (cs) in reply to Bush
    Bush:
    What about IQ and IN?

    IN is INdiana... IA is IowA. That leaves IR. (AF and NK are also available.)

  • Tom JP (unregistered)

    The database already had 3-character values in it. Trying to squeeze input into 2 characters sounds like a guaranteed break. TRWTF is using different data types/lengths for the same values in different places.

  • xous (unregistered) in reply to Charles400

    So was Yuriy's implementation actually simpler?

    I'm a bit rusty in SQL procs but was far as I can remember all of the issues Chareth pointed out would not increase the code complexity at all?

  • Rachael (unregistered)

    I'm with Chareth on point (1). He says there are 3-letter states in the existing data, i.e. there are customers already in the database who live in the 3-letter Australian states he gives as examples. Yuriy's char[2] solution won't work for them.

  • Stu (unregistered) in reply to occasional reader
    occasional reader:
    I've seen stuff like this before - people realising that the world doesn't rotate around the USA - where the 'state' column in addresses are relaxed to include provinces of Canada and abbreviated regions and counties of other countries.

    It just sounds like they don't sell outside of the US, which is pretty common among smaller retail companies.

  • (cs) in reply to frustrati
    Bush:
    occasional reader:
    I'm sure the senior developer is correct in that the US isn't planning to annex another state quite this minute :-)

    What about IQ and IN?

    Indiana is already a state.

  • Bob (unregistered)

    Why are they using datatypes in the stored procedure that differ from the columns in the database? Best practices dictate that you use the same datatype using the following construct:

    .<column>%TYPE

    That way, if something weird happens and the column type changes in the table, it won't hose all your stored procedures.

  • Bob (unregistered)

    Sounds like the existing data has customers from Australia in it. QLD-Queensland, NSW-New South Wales, etc.

    As for the money fields, common sense is never quite common, is it?

  • Sakamura (unregistered)

    HONK Wrong!

    US does have 3-letter places. The different armies.

    The address for one of my friend is (replacing identifying info with clearly invalid values)

    ABC (DE) Homer J Simpson ABC-123 Unit 45678 FPO AP 96601-1234

    In our case, the code is FPO instead of CA for California...

    So I guess that boss doesn't want to handle marines. Such a jerk.

  • (cs)

    If Chareth wants to stop getting stabbed in the heart with an exploding salty lemon dagger, he's going to have to quickly learn to stop "getting people in trouble" via CC, especially his boss.

  • Don (unregistered) in reply to Stu
    Stu:
    occasional reader:
    I've seen stuff like this before - people realising that the world doesn't rotate around the USA - where the 'state' column in addresses are relaxed to include provinces of Canada and abbreviated regions and counties of other countries.

    It just sounds like they don't sell outside of the US, which is pretty common among smaller retail companies.

    No, he said there was existing data related to other country codes.

  • Zap Brannigan (unregistered) in reply to Maurits
    Maurits:
    Yuriy's boss:
    if we get an order with a subtotal of octillion dollars then we’ll just make sure to discount it by sextillion dollars thereby getting us down to our precision number of 922 trillion dollars

    Buzzer

    Sorry, you lose... to get an order of octillion dollars down to 922 trillion dollars, you need to discount it by (almost) an octillion dollars, not merely by a sextillion dollars.

    They were using the difference in precision to pull off one of those rounding scams like in Superman III or Office Space. That's why the boss and Yuriy were so defensive.

  • Paul (unregistered)

    Hang on everyone

    I think I'm pretty much with Chareth here

    The database already has data with the 'big' fields. The database stores states in a 10 character field (and already has data > 2 characters in it), and it stores 'subtotal' as NUMERIC (28,12)

    So, since the database ALREADY stores the data in the 'big' form, the complaint that it would use too much space for the stored procedure to use that form is pretty specious. It isn't Chareth who has designed the database to store fields that are unnecessarily big, those were there before!

    When writing a stored procedure to use data from the database and process it, surely you MUST be able to handle any data which could be in the database.

    The boss has obviously ignored the point that there are already 3 character entries in the database. Reading them into a 2 character variable will break things because it'll be truncated and then misinterpreted. This is definitely a big flaw in Yuriy's version of the SP.

    The boss (and Alex) have also ignored the fact that you can't store numbers up to an octillion in a NUMERIC(28,12) field. That is 16 digits before the decimal and 12 after. So, you can 'only' store up to 10 quadrillion. Quite probably it would be OK to use 64 bit fixed point maths on this, as they were going to throw away 8 decimal digits, and ignore the very high numbers at the top which would fit in the NUMERIC field but not the 64 bit number, but in that case, why store data which will be ignored. Surely NUMERIC(15,4) would be the correct data type to use in the database, if that's the only data you're going to use).

    (At the very least, the SP should read the NUMERIC(28,12) and raise an exception if it would overflow the 64 bit variable).

    (BTW, maybe Chareth's extra complexity was that Yuriy was using 64 bit integers to do the maths, whereas Chareth needed a 'big number' library to do it properly. I'm not sure how using a 2 character state abbreviation instead of doing that properly would help).

    To me it sounds like the boss doesn't really know what he's doing, but is putting down the 'newbie' despite him having some good points.

Leave a comment on “Rule Number One”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article