If debugging is the process of removing errors,

RyuO · 2006-05-03 Reply Admin

ammoQ:
lrb:
Anonymous:
Anonymous:

But the error message IS correct! It read "The date entered is not valid. Dates must be entered in the MM/DD/YYYY format." which is perfectly fine. The first sentence describes the situation. The second one is additional information that simply does not apply in this case but is still correct.

I hope you're not a native English speaker. The second sentence may indeed be just a "helpful hint" thrown in there for the user, but nobody reading those two sentences in that order can possibly be expected to recognize that one is specific to their problem and the other is just general advice.

Fewer than 10% of the nonTechnical people that I know who use a PC as part of their work duties would have a problem distinguishing what was need from the error message given for the date. Of those 10%, more than 80% would get it after a 5 minutes of training. Of the remaining ones, almost no error message would suffice in allowing them to get it. If the users can't get it with the listed error message, then training is probably the best and certainly most economical solution.

I would imagine that given the size of the application in question and the apparent detailed and the apparent customized need for error messages it could easily cost well over $50,000 dollars (figured at $100/hr for time for all business stakeholders, developers, project managers, QA personnel, management, requirements analysts, etc. to derive the specifications, develop them, test them, and completely debug them to client's satisfaction: 5000 total man hours * 100/hour = $50,000) to modify the error handling system to meet client expectations. Now if the client manager who is autorizing payment for this application wishes to fork over the money, then the developers certainly should do it. However, extremely rare is the case where this is justified and even rarer is the case where a manager will agree to expend should a relatively extravagent amount of money for what will most likely be a negative ROI. BTW the $50,000 dollars does not include opportunity cost of delaying deployment and use of the application until the enhanced error messages were added and debugged.

Certainly the error message isn't the most clearest nor does it form a contract describing the desired results with vertually no room for misinterpretaion. However not very much description is needed for the vast majority of computer literate users to discern what needs to go there. It just doesn't make sense to pay for a Cadallic why a Chevy more that meets what is needed.

5000x100=50,000?

Maybe that's after an exchange rate calculation from wherever they make error messages... Abkhazia?!

But seriously, I agree that the error message was adequate. Moreover, it is standard practice to cram potentially extraneous information into messages. What percentage of messages in Microsoft apps fall into that category? 25%, maybe? The alternatives are to risk presenting a message out of context, or to burn a lot of developer hours trying to determine the context; neither alternative holds up well in maintenance. The problem will be around until we develop agents that watch what the user is doing from the background to keep track of the context.

Now, where can I buy a Cadallic?

lrb · 2006-05-03 Reply Admin

RyuO:
ammoQ:
lrb:

Anonymous:
Anonymous:

But the error message IS correct! It read "The date entered is not valid. Dates must be entered in the MM/DD/YYYY format." which is perfectly fine. The first sentence describes the situation. The second one is additional information that simply does not apply in this case but is still correct.

I hope you're not a native English speaker. The second sentence may indeed be just a "helpful hint" thrown in there for the user, but nobody reading those two sentences in that order can possibly be expected to recognize that one is specific to their problem and the other is just general advice.

Fewer than 10% of the nonTechnical people that I know who use a PC as part of their work duties would have a problem distinguishing what was need from the error message given for the date. Of those 10%, more than 80% would get it after a 5 minutes of training. Of the remaining ones, almost no error message would suffice in allowing them to get it. If the users can't get it with the listed error message, then training is probably the best and certainly most economical solution.

I would imagine that given the size of the application in question and the apparent detailed and the apparent customized need for error messages it could easily cost well over $50,000 dollars (figured at $100/hr for time for all business stakeholders, developers, project managers, QA personnel, management, requirements analysts, etc. to derive the specifications, develop them, test them, and completely debug them to client's satisfaction: 5000 total man hours * 100/hour = $50,000) to modify the error handling system to meet client expectations. Now if the client manager who is autorizing payment for this application wishes to fork over the money, then the developers certainly should do it. However, extremely rare is the case where this is justified and even rarer is the case where a manager will agree to expend should a relatively extravagent amount of money for what will most likely be a negative ROI. BTW the $50,000 dollars does not include opportunity cost of delaying deployment and use of the application until the enhanced error messages were added and debugged.

Certainly the error message isn't the most clearest nor does it form a contract describing the desired results with vertually no room for misinterpretaion. However not very much description is needed for the vast majority of computer literate users to discern what needs to go there. It just doesn't make sense to pay for a Cadallic why a Chevy more that meets what is needed.

5000x100=50,000?

Maybe that's after an exchange rate calculation from wherever they make error messages... Abkhazia?!

But seriously, I agree that the error message was adequate. Moreover, it is standard practice to cram potentially extraneous information into messages. What percentage of messages in Microsoft apps fall into that category? 25%, maybe? The alternatives are to risk presenting a message out of context, or to burn a lot of developer hours trying to determine the context; neither alternative holds up well in maintenance. The problem will be around until we develop agents that watch what the user is doing from the background to keep track of the context.

Now, where can I buy a Cadallic?

Well after correcting my typo of 5000 hours to 500 and muliplying it by $100/hr and then multiplying by the exchange rate of 27.17 Russian Rubles (the official currency in Abkhazia)/ $1 that would give us 1,358,500 rubles. ;)

www.Cadallic.com is where you can to go get your caddy. [:D]

2006-05-03 Reply Admin

Something that I think hasn't been said before: what about checking the DNS MX record on the domain part?
PHP's "checkdnsrr()" does just that (though I found some domains obviously can receive mails even though they only have a DNS A record, not an MX record) and has been quite successful in the application forms I developed. We also manually (yeah, those were the days) checked some of the most common typos, like typing "[email protected]" instead of "[email protected]" which we solved by a simple replace.

Of course nothing can really help you if the user enters "[email protected]" instead of "[email protected]".

For example, how could you possible trap "[email protected]" as an erroneous email address.

I don't know if "hotmal.com" actually exists. If it doesn't, you should be able to recognize it, see above.

This is why many web forms have you type in your email address twice.

And the user will copy/paste his mistake and be none the wiser. ;)

Maurits · 2006-05-03 Reply Admin

Anonymous:
Of course *nothing* can really help you if the user enters "[email protected]" instead of "[email protected]"

A standard technique is to require "activation" of accounts prior to use. The activation is implemented by emailing a magic link to the given email address. If the activiation link is clicked, it is reasonable to assume the email address is valid and belongs to a cooperative entity.

jsmith · 2006-05-03 Reply Admin

Maurits:
Anonymous:
Of course *nothing* can really help you if the user enters "[email protected]" instead of "[email protected]"

A standard technique is to require "activation" of accounts prior to use. The activation is implemented by emailing a magic link to the given email address. If the activiation link is clicked, it is reasonable to assume the email address is valid and belongs to a cooperative entity.

Let me point out once again that you may not be typing in your own address. This application may be used by customer service reps to help customers. Also, activation doesn't solve the error message problem..... If you don't get your activation message, how do you know it was because you keyed it incorrectly?

Just give a decent error message and be done with it. If the during the application design process you decide that this application needs extensive error messages, then do it. Otherwise, don't worry too much and tell the testers "That'll cost extra". BTW, what if the testers come back with a complaint about the colors, the lack of sound, and no foreign language support? Is everything that they deem "obvious" to be supported?

2006-05-04 Reply Admin

eddieboston:
Anonymous:

"The date entered is not valid. Dates must be entered in the MM/DD/YYYY format." seems ok though I wouldn't word it that way.

"The email entered is not valid." is not a *good* error message since it doesn't describe what the application requires of the user. Though I would expect any vaugly internet savy user to know what an email address should contain.

Why would anybody need to know what an email address should contain? They know what their email address is, and if what they typed is invalid, it's obviously not their email address, so all they need to do is change what they typed to their actual email address. Problem solved - nobody needs to know any rules.
And seriously, who is going to include comments in their email address on a web form? There's no need to worry about nested parentheses or any of that crap.

That's exactly what I was thinking. The error message only needs to point out that the entry is invalid. The user can look on their post-it note to re-type their email address (which presumably is, uh, valid).

Same with the date. "Date is invalid" is a perfectly fine error message, not requiring the computer to read the user's mind. It cannot possibly be the job of the application developers to help train the users on what a valid date is.

I agree that the testers were just lazy, or probably trying to get out of a contract.

Dylan

2006-05-05 Reply Admin

Anonymous:
eddieboston:
Anonymous:

"The date entered is not valid. Dates must be entered in the MM/DD/YYYY format." seems ok though I wouldn't word it that way.

"The email entered is not valid." is not a *good* error message since it doesn't describe what the application requires of the user. Though I would expect any vaugly internet savy user to know what an email address should contain.

Why would anybody need to know what an email address should contain? They know what their email address is, and if what they typed is invalid, it's obviously not their email address, so all they need to do is change what they typed to their actual email address. Problem solved - nobody needs to know any rules.
And seriously, who is going to include comments in their email address on a web form? There's no need to worry about nested parentheses or any of that crap.

That's exactly what I was thinking. The error message only needs to point out that the entry is invalid. The user can look on their post-it note to re-type their email address (which presumably is, uh, valid).

Same with the date. "Date is invalid" is a perfectly fine error message, not requiring the computer to read the user's mind. It cannot possibly be the job of the application developers to help train the users on what a valid date is.

I agree that the testers were just lazy, or probably trying to get out of a contract.

Dylan

Remember -- a regular expression (or the 700 lines of equivalent C code I naively wrote 3 months out of college) may tell you if the email address it's badly formatted, but it's very uncommunicative when it comes to telling you WHY it's badly formatted. That's a whole different ballgame. And, whether or not it's a REAL email address is another sport altogether. I wouldn't expect a tester to know this. In fact, it might be best if a tester didn't think about that, but it's true nonetheless.

2006-05-05 Reply Admin

Anonymous:
ParkinT:

If debugging is the process of removing errors,

the Programming must be the process of inserting them.

Not true. Programming is the process of removing the bugs from an empty directory tree. The first bug in most such empty directories is that they don't produce an executable when "make" is run. Then you have to fix "the executable doesn't do anything", followed by "the executable doesn't do everything", and "everything the executable does is wrong". Eventually, you get to "some things the executable does are wrong". At that point, you should remind the user how many bugs have already been removed from the piece of crap they gave you to start from.

I have two responses to this:

1. Are you married?

2. If you are not married, will you marry me?

Seriously, this is good. I posted this at work. (I hope you don't mind.) I actually had some youngsters come and ask what 'make' and what an 'executable' was. I'm feeling a little old and decrepit....but quite amused.

ammoQ · 2006-05-05 Reply Admin

chani:
Remember -- a regular expression (or the 700 lines of equivalent C code I naively wrote 3 months out of college) may tell you if the email address it's badly formatted, but it's very uncommunicative when it comes to telling you WHY it's badly formatted.

A simple finite state machine (hardly more than 50 lines of C code) is enough to find and explain most errors you can expect, like missing @, duplicate @, missing name, missing domain, illegal characters etc.

2006-05-05 Reply Admin

This looks like a requirement problem. Why is this a developer problem.

Gene Wirchenko · 2006-05-05 Reply Admin

ammoQ:
chani:
Remember -- a regular expression (or the 700 lines of equivalent C code I naively wrote 3 months out of college) may tell you if the email address it's badly formatted, but it's very uncommunicative when it comes to telling you WHY it's badly formatted.
A simple finite state machine (hardly more than 50 lines of C code) is enough to find and explain most errors you can expect, like missing @, duplicate @, missing name, missing domain, illegal characters etc.

REs may be very useful, but do not fit the bill here if a full solution is required. That means it is time to use something else. I do not think that an FSM will do the job either. (Are they not about the same? Am I missing a distinction, or are you forgetting about the matched parens?) Really, it is irrelevant. If you want to validate a value, use a way that works. THEN, worry about whether it is coolRE, ah, cooler than the other ways you could have used.

Sincerely,

Gene Wirchenko

ammoQ · 2006-05-05 Reply Admin

Gene Wirchenko:
ammoQ:
chani:
Remember -- a regular expression (or the 700 lines of equivalent C code I naively wrote 3 months out of college) may tell you if the email address it's badly formatted, but it's very uncommunicative when it comes to telling you WHY it's badly formatted.
A simple finite state machine (hardly more than 50 lines of C code) is enough to find and explain most errors you can expect, like missing @, duplicate @, missing name, missing domain, illegal characters etc.

REs may be very useful, but do not fit the bill here if a full solution is required. That means it is time to use something else. I do not think that an FSM will do the job either. (Are they not about the same? Am I missing a distinction, or are you forgetting about the matched parens?) Really, it is irrelevant. If you want to validate a value, use a way that works. THEN, worry about whether it is coolRE, ah, cooler than the other ways you could have used.

Sincerely,

Gene Wirchenko

My idea was this: first, use an RE to validate the email address. Such REs are readily available on the internet, so this part is almost no effort at all. If the RE fails, we need some way to explain what is wrong. The RE from the internet won't tell us, so let's use a (rather simple, to keep it cheap) FSM to find common errors. This FSM does not have to validate the email-adress in all details, just check for common mistakes. If the FSM finds no error (but the more rigid RE does), you can still output a generic "invalid email address" error message.

masklinn · 2006-05-07 Reply Admin

Gene Wirchenko:
I do not think that an FSM will do the job either.

Well, first of all it's THE FSM for you, and then you shall know that the Flying Spaghetti Monster is omnipotent and omniscient, so that wouldn't be a problem at all for him.

Yarr.

2006-05-09 Reply Admin

unklegwar:
" Good programmers check everything *they can think of*.
Good testers check everything the programmers *didn't think
of*.

Dr MindHacker
Open Source Developer
http://evercrack.cjb.cc"

The programmer DID test everything. It seems that invalid emails can't get through, therefore, he's performed his validation.

IF the specs require reporting to this level of detail, then the developer failed.

IF the specs merely said "validate email" then he's met his obligation.

IF there are no specs, then I would still side with the developer. A check for valid form is common and reasonable. The tester is out in left field. No program designed by the sane has a requirement for such detail in parsing an email.

And FYI, I AM professional, and I DO belong where I am. and we have Specs, requirements and a QA/Test team what knows what's reasonable, important and required.

Actually, it was the date check I was speaking about. The developer decided to test for a *content* error(whether a date per se is valid) yet flagged it as a *format* error (the structure of the date), that puts the developer in the wrong regardless of the specifications. Therefore, the programmer did NOT test everything. If you think that he did in face of those facts, then perhaps you should seek another line of work.

Dr MindHacker

lrb · 2006-05-09 Reply Admin

Anonymous:

unklegwar:
" Good programmers check everything *they can think of*.
Good testers check everything the programmers *didn't think
of*.

Dr MindHacker
Open Source Developer
http://evercrack.cjb.cc"

The programmer DID test everything. It seems that invalid emails can't get through, therefore, he's performed his validation.

IF the specs require reporting to this level of detail, then the developer failed.

IF the specs merely said "validate email" then he's met his obligation.

IF there are no specs, then I would still side with the developer. A check for valid form is common and reasonable. The tester is out in left field. No program designed by the sane has a requirement for such detail in parsing an email.

And FYI, I AM professional, and I DO belong where I am. and we have Specs, requirements and a QA/Test team what knows what's reasonable, important and required.

Actually, it was the date check I was speaking about. The developer decided to test for a *content* error(whether a date per se is valid) yet flagged it as a *format* error (the structure of the date), that puts the developer in the wrong regardless of the specifications. Therefore, the programmer did NOT test everything. If you think that he did in face of those facts, then perhaps you should seek another line of work.

Dr MindHacker

I'm not sure which calendar you use, but almost everyone on this planet uses the Gregorian. A Gregorian date is not formated correctly when using the format of MM/DD/YYYY when attempting to use the date 02/30/2005. The reason is that under no circumstance does February, the 2nd month in the calendar, have 30 days. This is not a content error, but is a format error. Perhaps you should go back and check your facts which in the light of day appear not to be facts at all.

BTW a content error would be enter a date like say 02/02/1700 and requiring all dates to be no older than 1 year in the past when originally entered. To test for a content error you must 1st have a correctly formated date, and then you can see if it fits into the domain of acceptable dates. 02/30/2005 is just a bunch of garbage that no one other the author can possibly know with a 50%+ chance of what was meant.

Gene Wirchenko · 2006-05-09 Reply Admin

lrb:
I'm not sure which calendar you use, but almost everyone on this planet uses the Gregorian. A Gregorian date is not formated correctly when using the format of MM/DD/YYYY when attempting to use the date 02/30/2005. The reason is that under no circumstance does February, the 2nd month in the calendar, have 30 days. This is not a content error, but is a format error. Perhaps you should go back and check your facts which in the light of day appear not to be facts at all.

You are funny. The format of MM/DD/YYYY is understood to be all digits. If you look at which digits were entered, you are looking at content. "02/30/2005" is thus a content error.

Sincerely,

Gene Wirchenko

lrb · 2006-05-09 Reply Admin

Gene Wirchenko:
lrb:
I'm not sure which calendar you use, but almost everyone on this planet uses the Gregorian. A Gregorian date is not formated correctly when using the format of MM/DD/YYYY when attempting to use the date 02/30/2005. The reason is that under no circumstance does February, the 2nd month in the calendar, have 30 days. This is not a content error, but is a format error. Perhaps you should go back and check your facts which in the light of day appear not to be facts at all.

You are funny. The format of MM/DD/YYYY is understood to be all digits. If you look at which digits were entered, you are looking at content. "02/30/2005" is thus a content error.

Sincerely,

Gene Wirchenko

yes, MM/DD/YYYY is understood to be all digits. It is also understood when MM = "02" that the range for DD is "01 to 28" with "29" added to that set for leap years only.

The format asks the user to enter the 2 digits representing month followed by the "/" character followed by the 2 digits representing day followed by the "/" character followed by the 4 digits of year which represent the date the user wants to enter. Collectively the digits must form a date or the format is not valid.

2006-05-10 Reply Admin

Joe Luser:
Having done some testing of other peoples' designs in the past, once a few silly/trivial/obvious faults are found, it is really tempting to then try to break it as hard as possible. And really satisfying when you do...

Not big. Not clever. But fun!

Well, I've been a tester and a code reviewer, and I am a developer and an end user, so hopefully I have most of the perspective thing down.

IMHO, not only is breaking applications really hard during test fun and enjoyable, but it helps to make a better product, and most of the time it isn't too horribly demoralizing - at least, not after the first few minutes of "WTF did that tester do!?! HTF did he do that?!?"

Not sure how that's relevant here, as the testers in question only found some trivial issues - which depending on the spec, may have been entirely in their minds, or they may have been real.

2006-05-10 Reply Admin

Anonymous:
The WTF is that the client is trying to annoy the developers. They can't possibly be serious that because the first screen fails on [rather dubious] negative tests that they can't test the other screens. You should positive test the entire application before you even begin negative testing.

The software does have a misleading error message, but that's only a small WTF.

I like to negative test first... but I don't turn in the report until I positive test - unless I find a security hole. I think that is because I like to break things. Nobody has complained about me doing that.

It can be fun how disconcerted the developers get when you tell them their application has a security hole within 20 minutes of them releasing the prototype to test. They tell you, "No, it doesn't." You tell them, "Do an 'ls /'." They see it now contains a file named, 'Yes, it does have a security hole!" They then need to ask your assistance in removing a file name with spaces and an exclaimation point.

FredSaw · 2006-05-11 Reply Admin

brazzy:
...you cannot tell what format a date uses just by looking at it if the day is <= 12. It is best to use the ISO standard YYYY-MM-DD when there's any chance that there will in international user base.

Okay. Makes sense to me. Thanks for the reply.

2008-07-18 Reply Admin

As far as I can tell, the real WTF here is that the testers complained about the error messages that refused to hold their hands, and yet they did not even read the first error message that they got when entering the date! If they had done more than just skim the error messages, they would tell them everything they needed to know.

next we'll see stuff like:

"In the 'color' field, we entered 'apple' and it said the color should be in RRGGBB format. The program ought to fix this by replacing 'apple' with 'red' so that people don't have to read cryptic error messages."

2008-12-28 Reply Admin

WWWWolf:
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.

If I am not mistaken, the linked page describes an RFC 822 address - http://www.ietf.org/rfc/rfc0822.txt section 6 - which is what goes in the email "To:", "From:", "Cc:", etc. fields - and not a RFC 822 addr-spec, which is what you put in the "email" field on web forms. The regular expression is therefore not restrictive enough - the intended syntax could be validated with way less code.

2010-08-31 Reply Admin

[email protected] is valid!

2010-12-06 Reply Admin

Seriously if you don't even know what format an email address has why would you be even filling that form...

2011-12-18 Reply Admin

The email tld problem is easy!!! Just retreive http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1, Filter out any blank lines or lines starting with //. and see is the tld in e.g.

[email protected]

is in the list. Works like a charm when the validating is done by a seperate program. Ex. email | webapp | [connects] verify_app [runs all the time and renews it's list once every hour] | [approves/declines email] webapp | [signals user the email is wrong or continues it's 'logic' ;)

CAPTCHA: nulla PS. Finally a captcha that is funny!

The Bug is in the Details

<FONT size=4>If debugging is the process of removing errors,</FONT>

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

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