02-17-2014, 09:03 PM
The beauty of programming, as belty notes, is that you can always count on the users to find and exploit any and every possible mistake, or loophole, or coding boo boo, to come up with interesting results...
East coast leading zero zip code? At least 5 characters for a name? Multiple middle and/or last names? How about throwing up a dialog box (or two, or whatever) to query and adjudicate any non-standard entry? The back end programming need only be as complicated as the boss wants to pay for... it can check and validate every possible scenario, or toggle a do not validate key for that record (so that somebody has to do it manually later). Run an error checker upon submit for each page is pretty standard to flag any bad/missing data. I get the feeling that a lot of programming is done by people/kids that aren't really clued in as to real world data entry, or are from some other country that doesn't have the same issues that we have here, so they're simply not familiar with the possible exceptions... boss says provide for "5 digit numeric zip code", and maybe they know the Red Sox won the World Series in the wake of the Boston Marathon bombing, but they don't know the zip code of Fenway Park has a leading zero. Boss says use 5 characters of name (for some fixed record length thingy), rather than "create an algorithm based on 5 characters of name, and if anme is less than 5 characters, normalize the algorithm using these specific characters...".
A lot of bad programming really boils down to a bad set specs in the beginning, so when you come across something that is out of whack, just realize your frustration is likely caused by poor communication between the spec-or and spec-ee.
East coast leading zero zip code? At least 5 characters for a name? Multiple middle and/or last names? How about throwing up a dialog box (or two, or whatever) to query and adjudicate any non-standard entry? The back end programming need only be as complicated as the boss wants to pay for... it can check and validate every possible scenario, or toggle a do not validate key for that record (so that somebody has to do it manually later). Run an error checker upon submit for each page is pretty standard to flag any bad/missing data. I get the feeling that a lot of programming is done by people/kids that aren't really clued in as to real world data entry, or are from some other country that doesn't have the same issues that we have here, so they're simply not familiar with the possible exceptions... boss says provide for "5 digit numeric zip code", and maybe they know the Red Sox won the World Series in the wake of the Boston Marathon bombing, but they don't know the zip code of Fenway Park has a leading zero. Boss says use 5 characters of name (for some fixed record length thingy), rather than "create an algorithm based on 5 characters of name, and if anme is less than 5 characters, normalize the algorithm using these specific characters...".
A lot of bad programming really boils down to a bad set specs in the beginning, so when you come across something that is out of whack, just realize your frustration is likely caused by poor communication between the spec-or and spec-ee.