• (cs)

    This is why I never validate user input.  It just leads to too many headaches. 

    [:D]

  • (cs) in reply to Sweets
    Sweets:

    If the specs for the app were to be for a 6-yr old then the fault lay on the developer(s)


    But even for a 6-yr old, the fault isn't with the developers (except they probably should have used a date picker).  The testers suggested that when you put in "02/30/2005" it tells you that the month and year are correct but they put in the wrong day.  How do you know?  What if they really meant to put in "03/30/2005"?  "I put in the wrong month, but it told me that the month was right and the day was wrong."
  • (cs)

    If debugging is the process of removing errors,

    the Programming must be the process of <FONT color=#ff0000>inserting</FONT> them.

  • (cs) in reply to ParkinT

    Sorry for the <FONT size=4>LARGE</FONT> font.  Bad WYSIWYG Editor.

  • Jeff (unregistered) in reply to mrprogguy
    mrprogguy:

    WWWWolf:
    Good luck coding an address validator! I mean, while you can validate a the correctness of an email address with a quite simple regex (http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html), writing an error handler that explains exactly what's wrong with the address would be surprisingly tricky. Bonus points if the error message ends "... (RFC 2822, section 3.4.1, sentence 3 - We know you don't care, we're just trying to annoy you)"

    Actually, you can't really validate a string as an e-mail address using just a regex.  I know everybody believes that, but you can't.  If you believe that, you haven't really read the RFC completely.



    Care to explain why?
  • Kiss me, I'm Polish (unregistered) in reply to GoatCheez

    The real WTF here is so many coders thinking they're smart and funny, yet can't recognise a tester that is smart and funny.
    I hate generic error messages like "Invalid e-mail" - they don't tell you what's wrong, since it's obvious for the coders. Users don't see the difference between a webpage and Excel, remember that.
    Face it - you don't write for yourselves. You write for these "monkeys". Nobody cares if you can handle the application.

  • (cs) in reply to JR
    Anonymous:

    <quote>Its called a datepicker people....use it.</quote>

    That solves the dates, but not email addresses.



    Sounds like we're ready for the 'email picker:'

    [image]
  • (cs) in reply to R.Flowers
  • TJ (unregistered) in reply to Tom

    Well lets clarify something here, are the testers the actual users or a seperate group of people working for the developers?

    Because you can't blame the testers if the are the client, I mean cmon. Its up to the developers to set expectations and manage the project. If the developers had done some prototyping with the client then the client would have an idea of what to expect, and not be shocked when they get the first screen.

    I think this comes down to bad developers who have no clue about the software process. Are the users tools? Yes. Are they the ones who pay your bills? uhh yea.

    How do you deploy a 4 mid-sized 4 module 36 screen app without any prototyping or user interaction? What did they expect, to just drop the software on the users and say presto. Definetly sounds like this was an off shore job... and another reason to give jobs like these to good software developers who can be onsite to get a feel for the users and the project.

  • (cs) in reply to Jeff
    Anonymous:
    mrprogguy:
    WWWWolf:
    Good luck coding an address validator! I mean, while you can validate a the correctness of an email address with a quite simple regex (http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html), writing an error handler that explains exactly what's wrong with the address would be surprisingly tricky. Bonus points if the error message ends "... (RFC 2822, section 3.4.1, sentence 3 - We know you don't care, we're just trying to annoy you)"

    Actually, you can't really validate a string as an e-mail address using just a regex.  I know everybody believes that, but you can't.  If you believe that, you haven't really read the RFC completely.


    Care to explain why?


    I did a bit of looking since I had seen regexes that purportedly did do so (and that were about 2K long).  Apparently, text in matched parens is permitted as comments.  The comments are ignored but are part of a valid E-mail address.  Matching parens can not be done with regexes.

    Sincerely,

    Gene Wirchenko

  • E (unregistered) in reply to JR
    Anonymous:

    <QUOTE>Its called a datepicker people....use it.</QUOTE>

    That solves the dates, but not email addresses.

    Date pickers suck for advanced users. In most systems that I've worked on efficiency of data entry has been a priority. Date pickers do not generally are not efficient to use since they require a mouse to drive. It may be that they would work for this application, but in general I think that a textbox with validation is superior.

     

  • BiG D (unregistered) in reply to R.Flowers

    That email picker just made my day, thanks :D

  • rich (unregistered) in reply to shaggz

    Anonymous:
    It seems like the customer is just trying to get out of the contract.  The only way this criticism would be remotely acceptable is if there were specific requirements for descriptive input validation. 

     

    My suspicion also. You must have worked for consulting firms too!

  • (cs) in reply to ammoQ

    ammoQ:
    GoatCheez:

    Let me make sure that my verification code is five billion lines wrong and littered with stuff that will check stuff like:

    (assuming we are using internet only e-mail)

    (snip)

    Given:
    [email protected]
    Response:
    (after 10 seconds)
    somewhere.com's mail server says that the user someone does not exist

    Given:
    [email protected]
    Response:
    (after 30 seconds)
    somewhere.com's mail server says you do not have rights to e-mail that account



    If a valid email adress is _really_ important for the system, you might decide to do exactly that.

    If a valid e-mail address is _really_ important for the system, you do a simple bounce-and-reply test.  Send an e-mail to the account.  If it bounces, disable the account.  If it doesn't bounce, require the user to perform an action based upon the e-mail.  If they don't do so within some time period, disable the account.

  • TJ (unregistered) in reply to E
    Anonymous:
    Anonymous:

    <quote>Its called a datepicker people....use it.</quote>

    That solves the dates, but not email addresses.

    Date pickers suck for advanced users. In most systems that I've worked on efficiency of data entry has been a priority. Date pickers do not generally are not efficient to use since they require a mouse to drive. It may be that they would work for this application, but in general I think that a textbox with validation is superior.

    Uhh last time I checked you dont need a mouse to use a datepicker.

  • (cs)

    Is it just me or is everyone skipping the giant WTF their process. Why wasn't the testing done prior to deployment?

  • (cs) in reply to E
    Anonymous:
    Anonymous:
    <quote>Its called a datepicker people....use it.</quote>

    That solves the dates, but not email addresses.

    Date pickers suck for advanced users. In most systems that I've worked on efficiency of data entry has been a priority. Date pickers do not generally are not efficient to use since they require a mouse to drive. It may be that they would work for this application, but in general I think that a textbox with validation is superior.

    Anything that needs a mouse seriously slows down data entry.  I am doing data entry where I work (about to turn it over) and, well, keyboards rule.

    Sincerely,

    Gene Wirchenko


  • (cs)

    <span style="font-size: 12pt;" times="" new="" roman="" ;="">We have all seen it before; the user always wants an idiot-proof program.  What they don't realize is if we made the program idiot proof they wouldn't have a job!  I guess the testers next memo will ask the program to read the mind of the user and input the data automatically.  Then again I don't then reading the mind of an idiot is a good idea. 

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.  So far, the Universe is winning!

  • (cs) in reply to R.Flowers
    R.Flowers:

    How about ".co.uk"?  And is . a valid character in the dropdowns?  I have two e-mail addresses that have . in them...  (on the username side)

  • (cs)

    Many years ago, 2 decades or there abouts, I was working on a version of a BASIC language interpreter that AT&T was testing for resale. One of the key developers frequently mistyped the LIST command so he added LSIT to the language.

    AT&T testers complained because LSIT wasn't documented. :)

  • (cs) in reply to ammoQ
    ammoQ:
    Anonymous:

    Like the above customer, he expected omniscient software that knew all for him.

     The employer could only dream of the fortune he would make if he could make that software program!



    Smells like GPS+RFID+stuff


    I wouldn't even say GPS is necessary, from the above conversation. Considering that it was in a warehouse, the warehouse's scanner/input software would presumably be smart enough to add that information.

    Now, to get _really_ fancy and track the item's location to within a few _feet_ then yeah - I agree. Considering the automagical functionality the customer seems to expect, I'd assume that your solution would be the one chosen after the next angry phone call.
  • (cs) in reply to BiG D

    Anonymous:
    That email picker just made my day, thanks :D

    I concur.

    I especially like the ALT text on the image.

  • Kiss me, I'm Polish (unregistered) in reply to PCBiz
    PCBiz:
    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.  So far, the Universe is winning!

    How does it feel to be a winner?
  • John Hensley (unregistered) in reply to GalacticCowboy
    GalacticCowboy:
    R.Flowers:

    How about ".co.uk"?  And is . a valid character in the dropdowns?  I have two e-mail addresses that have . in them...  (on the username side)


    R.Flowers,
    Again we are at a standstill in our testing. We continue to have trouble with the e-mail entry form. Two of the buttons are labelled "less letters" instead of the semantically correct "fewer letters." Our customers will find this very confusing. Furthermore, they do not indicate how to add a number or punctuation mark to the address instead of a letter. I have discussed this matter with our manager and he has determined that a working user interface is a condition of payment.

  • (cs)

    So in all seriousness, if you were the developer in this situation, and you got that response back from the testing team..

    ..What the heck would you do?

    I have no idea how would I react. Would you try to explain the simple concept of email addresses to the test team whom presumably is already familiar with the concept of the Internet? Or perhaps try to explain date formats to someone who may have at one point in their life actually written a date down on a piece of paper?

    Or do you just complain to their (or your) boss?

    I don't know if I'd feel bad, or angry...

  • Eli (unregistered) in reply to mrprogguy
    Actually, you can't really validate a string as an e-mail address using just a regex.  I know everybody believes that, but you can't.  If you believe that, you haven't really read the RFC completely.


    I agree, though I have seen a regexp that supposedly conformed to the whole standard. I can't confirm that it did because it was freakin huge.

    Then again, when was the last time anyone needed to put a COMMENT in the middle of an email address?

    (.+)@(.+)\.(.+) is good enough for most people
  • e.thermal (unregistered)
    Alex Papadimoulis:

    There's nothing like D[eployment]-day when it comes to finding out how good your code really is... [SNIP].

    This really burns my ass, I have had projects killed by testers like this.  The problem isn't the error messages, the error message could have been 4 pages long and explained all of the end user's problems going back to child birth.  But this kind of tester would still find problem.  This is a form of active resistance to change. This would be semi-excusable if it was simply ignorance on the testers behalf but the tester wanted the application to fail and didn't want to test the system.  I find when I come up to this kind of resistence,  the testers actions were deliberate and designed to create a level of FUD in management.  I feel for this programmer.

     

     

  • (cs) in reply to shaggz
    Anonymous:
    It seems like the customer is just trying to get out of the contract.  The only way this criticism would be remotely acceptable is if there were specific requirements for descriptive input validation. 

    I also smell something fishy here... Might be just that, the customers looking for a way out of the deal, probably from a real enterprisy price-tag. Seems a bit strange though that the customers didn't see the app before it was 'finished', that's a sure recipe for disaster, letting the architects, coders and/or managers decide what and how the customer wants the app...
  • TrashLock (unregistered) in reply to ammoQ
    ammoQ:

    If a valid email adress is _really_ important for the system, you might decide to do exactly that.

    That's why we invented E-Mail validation, where the system attempts to send an e-mail to the e-mail address entered, and the user needs to click a link or reply or something like that.
  • (cs)

    The real WTF is that they waited until they were "done" the application to get it to the testers.  If they had gotten the testers using the application as soon as they were done the first module (or better yet, the first feature of the first module) they would have learned what they were expecting earlier...  Then they could have adjusted to account for that - get out of the contract or help the testers bring their expectations to reality.

    It's a project management WTF, not user/tester WTF.  Big bang deployments never work.  Even if the software is bug-free (which it isn't), there's still a gap between what the user wants and what the
    team thinks they want (or can deliver).  You can close that gap early in the project by getting the users on the system as early as possible.

  • (cs) in reply to Xargon

    Xargon:
    They should re-code it so all errors are reported as: "A critical failure has occured between the keyboard and the chair."  I'll bet the testers replace their desks before they get it.

    OMG Laughing my ass off....Thanks... sad thing is you're probably right

  • (cs) in reply to ammoQ
    ammoQ:

    If a valid email adress is _really_ important for the system, you might decide to do exactly that.


    Unlikely. There are several problems with this approach:
    1) Just because a server is not reachable right now, doesn't mean it's not valid.
    2) There are actually a few mailservers that don't check the existence of the recipient until they're done receiving. Unless I'm mistaken, qmail does that. So ... more than just a few.
    3) Neither does SMTP have any other means by which to validate a recipient.
    4) And of course, checking access rights is fantasy.

    The typical thing to do is send a mail with a link to the validation site. Lot's of software does that.
  • PCBiz (unregistered) in reply to Kiss me, I'm Polish
    Anonymous:
    PCBiz:
    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.  So far, the Universe is winning!

    How does it feel to be a winner?



    Was this meant to be a personal attack on all the real programmers on this site or were you just having a brain fart and you meant to type

    My name is Kiss me, I'm a Pollock.... It feels good being a winner!
  • E (unregistered) in reply to TJ
    Anonymous:
    Anonymous:
    Anonymous:

    <QUOTE>Its called a datepicker people....use it.</QUOTE>

    That solves the dates, but not email addresses.

    Date pickers suck for advanced users. In most systems that I've worked on efficiency of data entry has been a priority. Date pickers do not generally are not efficient to use since they require a mouse to drive. It may be that they would work for this application, but in general I think that a textbox with validation is superior.

    Uhh last time I checked you dont need a mouse to use a datepicker.

    I suppose it depends on the date picker. I know the one that microsoft provides with the .net framework is tedious to use. The other example that I could quickly find was in outlook which allowed direct entry buy didnt prevent me from entering 02/30/2005 as a date.

  • (cs) in reply to HatTrick
    HatTrick:

    Xargon:
    They should re-code it so all errors are reported as: "A critical failure has occured between the keyboard and the chair."  I'll bet the testers replace their desks before they get it.

    OMG Laughing my ass off....Thanks... sad thing is you're probably right



    http://www.thinkgeek.com/tshirts/sysadmin/6692/
  • Dr.Jekyll (unregistered) in reply to Dave

    The email regex looks like this (from Perl's Regexp::Common module):

    (?:(?-xism:(?:(?-xism:(?-xism:(?-xism:(?-xism:(?-xism:(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)[^\x00-\x1F\x7F()<>[]:;@,."\s]+(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+))|(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)"(?-xism:(?-xism:[^\"])|(?-xism:\(?-xism:[^\x0A\x0D])))+"(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)))+)?(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)<(?-xism:(?-xism:(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)(?-xism:[^\x00-\x1F\x7F()<>[]:;@,."\s]+(?:.[^\x00-\x1F\x7F()<>[]:;@,."\s]+))(?-xism:(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+))|(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)"(?-xism:(?-xism:[^\"])|(?-xism:\(?-xism:[^\x0A\x0D])))+"(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)))@(?-xism:(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)(?-xism:[^\x00-\x1F\x7F()<>[]:;@,."\s]+(?:.[^\x00-\x1F\x7F()<>[]:;@,."\s]+))(?-xism:(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+))|(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)[(?:\s(?-xism:(?-xism:[^[]\])|(?-xism:\(?-xism:[^\x0A\x0D])))+)\s](?-xism:(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+))))>(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)))|(?-xism:(?-xism:(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)(?-xism:[^\x00-\x1F\x7F()<>[]:;@,."\s]+(?:.[^\x00-\x1F\x7F()<>[]:;@,."\s]+))(?-xism:(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+))|(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)"(?-xism:(?-xism:[^\"])|(?-xism:\(?-xism:[^\x0A\x0D])))+"(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)))@(?-xism:(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)(?-xism:[^\x00-\x1F\x7F()<>[]:;@,."\s]+(?:.[^\x00-\x1F\x7F()<>[]:;@,."\s]+))(?-xism:(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+))|(?-xism:(?-xism:(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)[(?:\s(?-xism:(?-xism:[^[]\])|(?-xism:\(?-xism:[^\x0A\x0D])))+)\s](?-xism:(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)+|\s+)))))(?-xism:\s((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|(?-xism:\s*((?:\s*(?-xism:(?-xism:(?>[^()\]+))|(?-xism:\(?-xism:[^\x0A\x0D]))|)+)\s)\s*))+)\s)\s*)*))

  • (cs) in reply to TJ
    Anonymous:
    Anonymous:
    Anonymous:

    <QUOTE>Its called a datepicker people....use it.</QUOTE>

    That solves the dates, but not email addresses.

    Date pickers suck for advanced users. In most systems that I've worked on efficiency of data entry has been a priority. Date pickers do not generally are not efficient to use since they require a mouse to drive. It may be that they would work for this application, but in general I think that a textbox with validation is superior.

    Uhh last time I checked you dont need a mouse to use a datepicker.

    In the last system I wrote, the users wanted to be able to enter in a date in a textbox with either a date picker or just by typing.  It wasn't because they were advanced users.  It's because they wanted "options," maybe dependent on whether they were in a clicking or a typing mood.  Sounds stupid, but if they are paying the bills...

  • (cs) in reply to Rank Amateur
    Rank Amateur:

    The customer is right that it would be better software if it told the user what was wrong. Sure, you could have an error message that says nothing more than “Huh?” and most of the time, the user will re-check their input an immediately recognize their mistake, but I’m sure we’ve all had moments where we stare and stare at some problematic input and only then realize (d’oh!) we type a “,” rather than a “.”, or the like. Sure would nice if the computer highlighted the exact character(s) causing the problem. Would speed up typing the correction if nothing else.

    Now that doesn’t make the customer’s complaints genuine show-stoppers, but it seems the customers have an incorrect sense of how programs do input validation, and how much work would be involved. They thought the programmers were being lazy, so they dinged them for it by halting testing.

    Lesson: customers are not a programmers. No WTF.

    --RA



    RA -- Would you care to share with us some examples of your validation code (with these detailed, specific error messages covering every possibility that could go wrong)?  I'd love to see it.  Maybe for dates, email addresses, credit card numbers, and so on.   I think it would be really helpful for the rest of us hackers to see how it *should* be done.


  • awfwaf (unregistered) in reply to PCBiz
    Wait a sec.  A 36 screen application is mid-sized?
     
    The one I'm working must be enterpricy for sure then.
  • (cs) in reply to poss
    Anonymous:
    Sounds like the tester hasn't finished writing their test cases, so has come up with a spurious reason to give themselves more time.

    (Yes, seen testers do that....)

    +1 Insightful
  • Alun Jones (unregistered) in reply to codeman
    codeman:
    I've worked on various systems where the requirements ranged the gamut from:
    let the application crash and burn for every little problem

    to:
    print a unique and descriptive error context-specific message for every
conceivable condition so the brain-dead users won't need to think.
    Or, you could use .NET, where it does both.
    [Sorry if that sounds peevish, I'm dealing with an ASP.NET app.]
  • SnarkSnark (unregistered) in reply to Dave
    Anonymous:

    So the WTF is that the customer wanted better error handling?

    > 03/30/2005

    I assume this was 02/30/2005 as used a bit lower down. The error message *is* deceptive, it indicates that the format is wrong but the actual problem is that the date is not valid.

    On the email validation, anybody here who deals with people typing in emails knows that they get it wrong a lot of the time. I frequently see [email protected] or [email protected] and plenty of others. The customer had it wrong to some degree--any domain such as .info can have emails as well--but still, it would be good to be more specific about what was wrong. A few regular expressions can handle this easily.



    How would a regular expression help with your second example?  [email protected] is perfectly legitimate (assuming there's a domain out there named "hotmal".)

  • awfwaf (unregistered) in reply to Jeff S
    Jeff S:
    Rank Amateur:

    The customer is right that it would be better software if it told the user what was wrong. Sure, you could have an error message that says nothing more than “Huh?” and most of the time, the user will re-check their input an immediately recognize their mistake, but I’m sure we’ve all had moments where we stare and stare at some problematic input and only then realize (d’oh!) we type a “,” rather than a “.”, or the like. Sure would nice if the computer highlighted the exact character(s) causing the problem. Would speed up typing the correction if nothing else.

    Now that doesn’t make the customer’s complaints genuine show-stoppers, but it seems the customers have an incorrect sense of how programs do input validation, and how much work would be involved. They thought the programmers were being lazy, so they dinged them for it by halting testing.

    Lesson: customers are not a programmers. No WTF.

    --RA



    RA -- Would you care to share with us some examples of your validation code (with these detailed, specific error messages covering every possibility that could go wrong)?  I'd love to see it.  Maybe for dates, email addresses, credit card numbers, and so on.   I think it would be really helpful for the rest of us hackers to see how it *should* be done.


    WTF?  Did you read his post, or did you just spaz out when you skimmed it?
     
    He's saying it would BE NICE IF ERROR MESSAGES WERE LIKE THAT.  Of course, we all realize that THAT WOULD BE REALLY HARD TO DO, AND A TOTAL BITCH.
     
    Also, he's saying that the CUSTOMER'S EXPECTATIONS WERE NOT MANAGED PROPERLY.
     
    COMPRENDE?
  • bobnik (unregistered) in reply to Beek
    Quite a lot of developer arrogance here...
     
    While the testers weren't exactly polite, their complaints and reaction are absolutely valid. This is assuming that descriptive error messages was part of the requirements, and that they set high standards for usability and quality.
     
    Any demanding guidelines for usability will tell you that when validating user-entered data, your system feedback has to explain exactly what is wrong with ill-formed or illegal values.
     
    The testers could have gone on, obviously, but there was really no point when there were so many basic problems on the first form. They would be wasting their time pointing out the same things over and over again. From their point of view, the system was incomplete. Better to send it back to the developers, have them fix this whole class of problems, then test the finished system.
  • (cs) in reply to PCBiz
    Anonymous:
    Anonymous:
    PCBiz:
    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.  So far, the Universe is winning!

    How does it feel to be a winner?



    Was this meant to be a personal attack on all the real programmers on this site or were you just having a brain fart and you meant to type

    My name is Kiss me, I'm a Pollock.... It feels good being a winner!

    Hmmm... Actually I think it was meant as a more or less personal attack on you and you only... Not sure though :P
  • (cs) in reply to WWWWolf
    WWWWolf:
    Good luck coding an address validator! I mean, while you can validate a the correctness of an email address with a quite simple regex (http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html)

    I like the definition of "quite simple" that you're using.

    On the broader topic... wow, I think this is the closest to unanimous agreement I've ever seen on the TDWTF forum. Guess I'll chime in with...

    1. First of all, any bug report that starts with "Since the program knows..." is going to be "RESOLVED - WONTFIX", with a comment saying "Since you know so much more about how my code works than I do, fix it yourself." If I'm feeling nice, I might add something like "If you'd like to be polite and restate that as a question, we can start a discussion of the issue, wherein I'll be happy to tell you what the code does and doesn't 'know'."

    2. Yes, these are arguably valid bugs... P4 bugs, that is. Go ahead and file it as a P4 to get the issue raised: depending on how the validation code is structured, it might really be that easy to change the message. Maybe a product manager will have a chat with the engineer and decide whether it's worth spending time on. A good PM [*1] would probably mark it "RESOLVED - INVALID" without even bothering the engineer; a slightly less good one would ask first and then do it. But there's nothing wrong with QA filing it -- that's how the process is supposed to work, and it's why Bugzilla has those tags.

    3. But to characterize these as "major issues" is completely out of line -- the actual validation wasn't even wrong; they're just complaining about the messages! And to claim that these items make it impossible to proceed with testing the remaining screens is just willfully stupid. Especially if they know so much about how the code works (see (1.) above), they should realize that these are not deep structural issues by any stretch, and that they're irrelevant to the behavior of the rest of the system.


    --
    [1] Yes, they do exist, they're just a bit rare -- I'd say "good PM" is somewhere between "hot geek girl" and "unicorn" on the reality scale.

  • Mulder (unregistered) in reply to awfwaf

    Statements like "There are so many basic issues wrong with the app, I refuse to continue testing" are the kind of thing you hear from bosses when they have a bad day.
    Like you have that 30,000 code lines application which does some amazing things (and does them right BTW), yet the boss focuses on the fact that you cannot enter "#'ßü$" as the project name on the first screen and calls your application "buggy as hell".
    In fact, I've seen teams of beta testers being forced to sit out for two days just waiting until the developers fixed some browser-related layout quirks, instead of continuing to test the functional part of the application.
    But that's a WTF every developer has had to face in his life. sigh
    Recent example: an old application which is riddled with bugs was to be replaced with a newer and better version. However the responsible manager refused to green-light the launch because he thought the font size was off and the line separators in tables were a few pixels too thick. So his decision was "the buggy application remains online until the flaws with the new one are fixed". :grrr:

  • (cs) in reply to ParkinT
    ParkinT:
    Sorry for the <FONT size=4>LARGE</FONT> font.  Bad WYSIWYG Editor.

    Presumably that'd be a WYSINWYG editor; unfortunately, they're more common than you'd hope. Besides, you shouldn't expect anything else from this site; just got to HTML view, enter your post with a minimum of formatting, cross your fingers and hit the button...

  • (cs) in reply to bobnik
    Anonymous:
    Quite a lot of developer arrogance here...
     

    Huh? Arrogant developers? Here? On TDWTF??? W - T - F ?!?!?!?
  • SnarkSnark (unregistered) in reply to Rick
    Rick:
    Many years ago, 2 decades or there abouts, I was working on a version of a BASIC language interpreter that AT&T was testing for resale. One of the key developers frequently mistyped the LIST command so he added LSIT to the language.

    AT&T testers complained because LSIT wasn't documented. :)


    If I was testing I'd complain too.  I'd hate to be a developer where I have a variable for (for a random example) "local situation" named LSIT  and I keep getting the following error:

    10 Let LSIT = 99
               ^
    Syntax Error: Token at position 8 not recognized.

Leave a comment on “The Bug is in the Details”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article