- 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
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.
Admin
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.
Admin
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."
Admin
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.
Admin
Wait. Where is the "last entry" from "a couple days later"?
Admin
Admin
And what round would that be?
Admin
Admin
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
Admin
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".
Admin
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?"
Admin
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.
Admin
Admin
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.
Admin
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.
Admin
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?
Admin
So.... is TRWTF that what.thedailywtf.com is down?
Admin
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.
Admin
How is this different from any other tester I have ever worked with?
Admin
TRWTF is the imperative tone of this article.
Admin
Admin
Status changed to "This did not happen".
Admin
"4 decimal places should be good enough for everybody."
-Mark Winston. General Manager at bank in California.
Admin
Admin
Admin
Right-click -> View Image returns a png file with the following error:
"Service Unavailable
HTTP Error 503. The service is unavailable."
Admin
Good testers. Kudos.
Admin
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.
Admin
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.
Admin
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:
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.
Admin
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.
Admin
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.
Admin
Indeed 7 characters is something completely different from 7 decimal places (1.2345678)
Admin
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.
Admin
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.
Admin
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.
Admin
I thank him, too, for a well written story.
Admin
Perhaps not, but it often involves Pigs of some type, and the occasional (typically very surprised) Sheep.....
Admin
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.
Admin
Admin
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.
Admin
TESTER: Ever is redundant and should be removed.
Admin
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!
Admin
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.
Admin
Admin
Admin
The suspense is killing me... WHERE IS IT?!
Admin
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.
Admin
It said you're not smart enough for Discourse.
Admin
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.