If you are a coder of any kind, you need to read this post. I’ve coded tons of stuff in my life, and every time I have to do any kind of data validation, whether it’s form data validation on a website, or object data validation in a desktop or database application, I always consider the data source; the user.
There are two main reasons for using data validation; it confines the input data to a small subset of possibilities, and it reduces the need for excessive error handling by trying to head off errors before an error condition occurs.
The problem with data validation is; developers don’t want to write proper error handling routines (they are lazy), and they assume users are idiots (correct most of the time). The problem comes about when your data validation process makes wildly inaccurate assumptions about what is and is not correct. What’s worse, many times data validation is totally unnecessary, and in some cases reduces a valuable piece of software to an unusable pile of crap.
Case in point: For internal Windows domains, I’m a fan of the “.local” TLD. This is not a valid Internet TLD, but that’s ok because Windows domains are not Internet domains, and it’s usually best to separate a company’s Internet domains from it’s internal domains.
The problem with this, is that some software insists on validating email addresses to the point where utility turns to futility. A good email validation process will only check that there is no white space, that there is an @ symbol in there, and the domain data following it has at least one dot. This is a perfectly fine email address validation process. It will catch 99% of all typographical mistakes an end user could make, aside from typo errors such as entering the wrong email address all together.
However, some developers go too far. They presume you are such a complete retard, they insist on validating the TLD of the email address. Not only is this presumption supremely arrogant, it is also flat out stupid because new TLDs are created from time to time. The format of an email address will never change, but the TLDs may. So why hard-code a data validation process that will routinely become obsolete, and then do something even worse; completely block the user from continuing even though they entered a valid email address?
This particular issue pisses me off because the developer is making a call on something they should not be making a call on. Just because you can do something, doesn’t mean you should, and developers are making assumptions on things they are flat out wrong about. In my case, the “.local” TLD is a perfectly legal domain name in a Windows domain naming system. Hell, any word could be the TLD in a Windows domain name system. I could have “my.company.hamburgers” if I wanted. So what the hell is a developer doing, telling me I can’t use those names in my internal domain/email system?
Here’s an example of what I’m talking about. I’m setting up a phone manager server for our internal digital phone system. For our internal devices, we use our internal “.local” domain name suffix in the email addresses assigned to that device. There is no reason to assign an email address on an external Internet domain to a device used internally. So, I set our enterprise messaging system’s email address to EM@OB.LOCAL which is perfectly functional inside our company. However, this phone manager software will not let me use that domain in the email address, and errors out:
Of course I could change the email address to an external domain on a “proper” Internet TLD, but it would not comply with company convention. It would also violate my principles to simply fake the email address because some piss ant developer decided I was a retard who couldn’t enter an email address properly.
There are other reasons I didn’t want to put a different TLD in there, which I will not get into because it’s not the point I’m trying to make. The developer should have simply checked the format of the email address, not the TLD content. If you are a developer who insists on validating the TLD in an email address, then at least make the pop-up alert window a simple notice and not a block to saving the setting and moving forward.
Finally, if you are a developer of a software package that is designed to be installed by an IT tech person or IT administrator of any kind, please give us some credit. Don’t code everything with kid safe corners and blocking data validations, we do know what we’re doing.
Tags: software
[…] few months ago I had a little rant about validation, and how developers had to be more thoughtful and less presumptuous. Lately […]