• pjt33 (cs)

    I'm not sure whether the WTF is Alex or the writeup, but I can see a clear difference between limiting the number of decimal places to 7 and limiting the number of characters to 7. Even if no security price is greater than 1 unit, the decimal delimiter will be a character.

  • GettinSadda (cs)

    Are we missing the WFT part?

    The user requested a limit of 7 DPs, a fix was coded, tester clarified that the limit was supposed to be applied after a full number was entered (with rounding as required) and the programmer updated it to work this way.

  • G (unregistered)

    I read that as a lazy dev. Looks like "just round it up if I have too many decimal places" was an acceptable fix in the end. I'd have been worried if the user wanted the more convoluted "check I entered 7 decimals then don't let me enter the 8th while I'm still typing in the field."

  • cyborg (unregistered)

    TRWTF is that the GUI would be trusted with this. If you need to restrict something then whatever is generating or passing that value should be doing so. Relying on the GUI to generate correct values and having downstream things accept that as Gospel is a recipe for fuck-ups. Restrictions in the GUI should be considered a sanity check - not the solution.

    CAPTCHO - This is a sino my god.

  • frost (unregistered)

    Wait. Where is the "last entry" from "a couple days later"?

  • TGV (cs) in reply to frost
    frost:
    Wait. Where is the "last entry" from "a couple days later"?
    I'm hanging there too.
  • pippo (unregistered)

    And what round would that be?

  • RandomGuy (unregistered) in reply to TGV
    TGV:
    frost:
    Wait. Where is the "last entry" from "a couple days later"?
    I'm hanging there too.
    I guess the final entry is
      [Advertisement] Have you seen BuildMaster 4.3 yet? 
  • Jim (unregistered)

    Isn't this quite a big change to making on one persons request? What if another user needs to enter 9DP. He may not even know it is being rounded to 7

  • amomynous (unregistered)

    TRWTF is automatic rounding on any value that means cash. IMHO, either refuse to accept anything invalid or beyond limits, or accept whatever was typed and blame the user afterwards if he complains about anything: "you typed that, we don't adjust the values, so be careful next time".

  • RFox (unregistered) in reply to TGV
    TGV:
    frost:
    Wait. Where is the "last entry" from "a couple days later"?
    I'm hanging there too.

    It's above that caption.

    I was waiting, however for the dialog box:

    "Adobe Flash has a new update available do you want to install?"

  • Paul (unregistered)

    Err. Re "And now, a couple of days later, the final entry in the history log."

    That sentence seems to require there to be one more log entry, at the end of the post. Is there a C'n'P mistake in this WTF.

  • RandomGuy (unregistered) in reply to RFox
    RFox:
    TGV:
    frost:
    Wait. Where is the "last entry" from "a couple days later"?
    I'm hanging there too.
    It's above that caption.
    Yes, that seems to be the case. However, the "a couple of days later" does not really make sense then. And it would be interesting what happened between May 8th and June 30th.
  • cyborg (unregistered) in reply to Jim
    Jim:
    Isn't this quite a big change to making on one persons request? What if another user needs to enter 9DP. He may not even know it is being rounded to 7

    It is entirely possible that the exchange may only quote to a certain precision for the instrument - that's entirely reasonable although 7dp doesn't immediately make me think of anything I know. It's impossible to know without additional details but as it says this is for system X then the right answer is to make sure that before it goes to system X it's rounded because that's a requirement of system X's input. The user should be able to choose the dp displayed to him.

    Again TRWTF is the fact no-one in this story seems to know these things should be designed.

  • Data Dude (unregistered) in reply to amomynous
    amomynous:
    TRWTF is automatic rounding on any value that means cash. IMHO, either refuse to accept anything invalid or beyond limits, or accept whatever was typed and blame the user afterwards if he complains about anything: "you typed that, we don't adjust the values, so be careful next time".

    This is exactly correct. If the business as a whole wants it at 7 decimal places and can define the type of rounding to use, then fine. Otherwise, capture the data as it actually is. You can round on reports. And then if they don't like it rounded there, you can change it. If you change it at the point of entry and decide later that was a bad idea, well, you're out of luck.

  • Walky_one (unregistered)

    I also would be interested in the "a couple of days later" message...

    But generally I want to thank Bruce Johnson for giving a nice and clean WTF "story" without embellishments and forced dramatics. Just the technical details which can then speak for themselves. (Or in other words: Finally a WTF where I don't instictively ask myself "What of it is true?")

    Captcha: Saepius. How good is a captcha if it already appears as auto-complete in the edit field of the browser?

  • Accalia Elementia (unregistered)

    So.... is TRWTF that what.thedailywtf.com is down?

  • anon (unregistered) in reply to RandomGuy
    RandomGuy:
    And it would be interesting what happened between May 8th and June 30th.

    After a change request committee was picked to elect a change request board of change requesters the issue was in limbo for some weeks while Hanzo fixed the video-conference hardware. Then a two day summit commenced that eventually gave the go-ahead to implement the change.

  • rekcuf rehtom uoy siht esrever (unregistered)

    How is this different from any other tester I have ever worked with?

  • Andrew (unregistered)

    TRWTF is the imperative tone of this article.

  • luctus (unregistered) in reply to Accalia Elementia
    Accalia Elementia:
    So.... is TRWTF that what.thedailywtf.com is down?
    No, TRWTF is that it was ever up in the first place.
  • Nagesh (cs)

    Status changed to "This did not happen".

  • Nagesh (cs)

    "4 decimal places should be good enough for everybody."

    -Mark Winston. General Manager at bank in California.

  • Coward! (unregistered) in reply to frost
    frost:
    Wait. Where is the "last entry" from "a couple days later"?
    Unless he's doing that fucking annoying skullfuckery where he hasn't indicated where the explanation for the table actually is and then decides to chop and change every second table.
  • Kempeth (unregistered) in reply to frost
    frost:
    Wait. Where is the "last entry" from "a couple days later"?
    Maybe that's because the editor of the page truncated it to N characters instead of N characters after the end of the story.
  • eman_ruoy (unregistered) in reply to Paul
    Paul:
    Err. Re "And now, a couple of days later, the final entry in the history log."

    That sentence seems to require there to be one more log entry, at the end of the post. Is there a C'n'P mistake in this WTF.

    Right-click -> View Image returns a png file with the following error:

    "Service Unavailable

    HTTP Error 503. The service is unavailable."

  • Vlad Patryshev (unregistered)

    Good testers. Kudos.

  • DrPepper (cs)

    The issue is the CODER, but not for the reason you think. He's fallen into the trap -- make the change the QA person thinks you need to make.

    Instead, he should have pushed back. The program obviously meets the requirements exactly. If the desire was to allow entry of more than 7 characters, then the BA got the requirement wrong; and needs to update the requirement. If the QA person expected to be able to enter more than 7 characters, then he read the requirement wrong; and must be educated.

    In no way should the developer make a change to his code simply because QA asked him to.

  • Jack (unregistered) in reply to DrPepper
    DrPepper:
    The issue is the CODER, but not for the reason you think. He's fallen into the trap -- make the change the QA person thinks you need to make.

    Instead, he should have pushed back. The program obviously meets the requirements exactly. If the desire was to allow entry of more than 7 characters, then the BA got the requirement wrong; and needs to update the requirement. If the QA person expected to be able to enter more than 7 characters, then he read the requirement wrong; and must be educated.

    In no way should the developer make a change to his code simply because QA asked him to.

    +1 Usually the business analyst and/or product owner define the requirements, not QA.

    I think a lot of the comments are coming from people who assume the original solution only allowed 7 characters total, but I assume it was allowing 7 characters after the decimal point. It wouldn't be the first time I've seen a tester comment that doesn't accurately explain what they think is broken.

  • Geoff (unregistered) in reply to Data Dude
    amomynous:
    This is exactly correct. If the business as a whole wants it at 7 decimal places and can define the type of rounding to use, then fine. Otherwise, capture the data as it actually is. You can round on reports. And then if they don't like it rounded there, you can change it. If you change it at the point of entry and decide later that was a bad idea, well, you're out of luck.

    no No NO. You capture the data as it will be transacted upon. In this case some other system, convention, or standard exists (The DLS system and whatever reasons it uses 7dp). The developer here needs to ask:

    What should I do when confronted with more than 7dp? The options I can reasonably implement are:

    1. Round in some carefully specified fashion
    2. Reject the input with an error message
    3. Alter the UI so that it will not accept input beyond 7dp.

    What he should not do is store the data at 9dp or whatever, potentially transact at 9dp and then report at 7dp. If he does that the first time someone transacts half a million shares and then complains their account balance should be $0.57 higher business users are going running reports and ploping the values into Excel. They will then wonder why they cannot reproduce any of the reported values.

    Nope if there are established accepted and document rounding rules, you need to implement and follow them. If not you need to handle input as entered EVERYWHERE doing every calculation at full precision and reporting at full precision. If there are limits they need to be imposed as early as possible so users know exactly what is going on.

  • Nagesh (cs) in reply to DrPepper
    DrPepper:
    The issue is the CODER, but not for the reason you think. He's fallen into the trap -- make the change the QA person thinks you need to make.

    Instead, he should have pushed back. The program obviously meets the requirements exactly. If the desire was to allow entry of more than 7 characters, then the BA got the requirement wrong; and needs to update the requirement. If the QA person expected to be able to enter more than 7 characters, then he read the requirement wrong; and must be educated.

    In no way should the developer make a change to his code simply because QA asked him to.

    as far as dEveloper go, he should not make any change unless sufficient authorization has been obtained in triplicate and all workflows have been completed.

  • No not really (unregistered) in reply to Walky_one

    You mean other then the whole bit about live stock? As there's a bunch of rancher\developers that would read this and get confused? Cowboy coding doesn't actually involve real cows.

    Even the technical details aren't right, as others have pointed out, 7 decimal points is not the same as 7 charaters.

    I think someone misread this and thought it was funny.

  • Hasse de great (unregistered)

    Indeed 7 characters is something completely different from 7 decimal places (1.2345678)

  • typewriter (unregistered)

    Going from the scant evidence it seems the original request was to limit the value to seven decimal places, but the submitted change limited it to seven characters in total. So 999.1234567 was rejected because there's 11 characters though only 7 decimal places.

  • Johnboy (unregistered) in reply to Geoff
    Nope if there are established accepted and document rounding rules, you need to implement and follow them. If not you need to handle input as entered EVERYWHERE doing every calculation at full precision and reporting at full precision. If there are limits they need to be imposed as early as possible so users know exactly what is going on.

    I think if there is some requirement to hold data with larger than 7 decimals, then storing it as such and rounding elsewhere is probably best.

    If there is no such requirement, then by accepting data from the user in that format is inviting disaster in the future and ... more rounds of Superman III jokes.

  • C-Derb (unregistered) in reply to typewriter
    typewriter:
    Going from the scant evidence it seems the original request was to limit the value to seven decimal places, but the submitted change limited it to seven characters in total. So 999.1234567 was rejected because there's 11 characters though only 7 decimal places.
    This assumes that the tester accurately described the difference between the code that was submitted and the requirement to allow up to 7 decimal places. Call me crazy, but I trust the developer more than the tester.

    The way the story is laid out, it sounds like the tester rejected the code change because he could only enter 53.1234567, but could not enter 123.12345678 to verify that only 7 decimal places were allowed.

  • CM (unregistered) in reply to Walky_one

    I thank him, too, for a well written story.

  • Just Sayin... (unregistered) in reply to No not really
    No not really:
    Cowboy coding doesn't actually involve real cows.

    Perhaps not, but it often involves Pigs of some type, and the occasional (typically very surprised) Sheep.....

  • TheSabre (unregistered)

    Rounding up to 7 DPs? Sounds like Alex is working with his buddies Michael and Samir to divert the extra 100,000,000ths of a penny to a separate bank account somewhere.

  • the beholder (unregistered) in reply to RandomGuy
    RandomGuy:
    RFox:
    TGV:
    frost:
    Wait. Where is the "last entry" from "a couple days later"?
    I'm hanging there too.
    It's above that caption.
    Yes, that seems to be the case. However, the "a couple of days later" does not really make sense then. And it would be interesting what happened between May 8th and June 30th.
    What development company in the world doesn't have their developers swamped in tasks? June 30th was most likely the first day Alex was available to work in this issue.
  • chubertdev (cs)

    Letting the user enter anything, even if it's not valid? That's how we do it at my company.

    Not only do we have security by obscurity, we have validation by obscurity.

  • JRI (unregistered) in reply to rekcuf rehtom uoy siht esrever

    TESTER: Ever is redundant and should be removed.

  • gnasher729 (unregistered) in reply to typewriter
    typewriter:
    Going from the scant evidence it seems the original request was to limit the value to seven decimal places, but the submitted change limited it to seven characters in total. So 999.1234567 was rejected because there's 11 characters though only 7 decimal places.

    No, you got that wrong.

    The code change, as requested, limited numbers to seven decimals. However, the input had always been limited to seven characters. Before the change, and after the change. Because the limitation of seven input characters, creating a number with more than seven decimals was and had always been impossible. And since the tester could not enter numbers with 8 or more decimals, it was impossible to test whether a number with 8 or more decimals would be truncated correctly to seven digits.

    Quite sensibly the code change which was impossible to test was rejected.

    PS. Safari filled out the captcha automatically after three letters!

  • herby (cs)

    The unsaid between May 8th and June 30th:

    Conferences were called and everyone weighed in the risks involved in changing values. It was decided that eventually the rounding of securities to 7 digits would actually be truncating. The "left over" was to be put into the "Z9" account for distribution between the principals after being transferred to a bank in the Caymans. Soon after the executive staff planned a vacation, and their retirement. This continues to this day, and had developed into a nice nest egg.

    See: Equity Funding.

  • Norman Diamond (unregistered) in reply to Accalia Elementia
    Accalia Elementia:
    So.... is TRWTF that what.thedailywtf.com is down?
    What happened, a hard discourse failure?
  • Norman Diamond (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Accalia Elementia:
    So.... is TRWTF that what.thedailywtf.com is down?
    What happened, a hard discourse failure?
    What did SMART testing say?
  • Hannes (unregistered)
    And now, a couple of days later, the final entry in the history log.

    The suspense is killing me... WHERE IS IT?!

  • Abe (unregistered)

    Reminds me of the QA we had in previous work. I was tasked to write a piece of code which converts any number to fit N>=4 characters (not counting decimal point). So 10000 would be 10.0K, 100 000 would be 100K, 1.7M, 2.70G etc... I ran the code through tests up to gazillion, checked it in and went to pub. Three hours later i got a call from our (moron) PM to come back to "fix it" because it "shows 7 instead of 9". I was pretty drunk at that time but i knew this was nonsense. Long story short, my colleague called me half a hour again and it turned out that another graphic element on screen was covering the first number of the field, and because it "looked like 7" , the QA reported it shows 7 instead of 9.

  • cyborg (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Norman Diamond:
    Accalia Elementia:
    So.... is TRWTF that what.thedailywtf.com is down?
    What happened, a hard discourse failure?
    What did SMART testing say?

    It said you're not smart enough for Discourse.

  • nmclean (unregistered) in reply to cyborg
    cyborg:
    TRWTF is that the GUI would be trusted with this. If you need to restrict something then whatever is generating or passing that value should be doing so. Relying on the GUI to generate correct values and having downstream things accept that as Gospel is a recipe for fuck-ups. Restrictions in the GUI should be considered a sanity check - not the solution.

    CAPTCHO - This is a sino my god.

    I think you're assuming too much here. The point of the change is "to conform to the limitation of a maximum of seven decimal places found in the DLS system." This doesn't sound like a display issue. Yeah, maybe "DLS system" is just some kind of reporting standard, and thus trimming it just before outputting it is fine. But the more likely interpretation is that this system actually processes the input value and affects the outcome. In this case, that is the value that should be stored from the beginning so that all calculations done in both the internal and external apps are consistent.

    And so the app should not allow the user to enter more than 7 decimals, or if it does, it should very loudly warn the user that the given value is not the one that is actually entering the system. The fact that the user asked for this behavior is the WTF. The only thing we can fault "Alex" for is actually implementing this "fix" without questioning it further.

Leave a comment on “Issue History”

Log In or post as a guest

Replying to comment #:

« Return to Article