“Can’t you just add that feature today!?”
“Can you add a simple update for this!?”
“It’s obvious, it really shouldn’t take very long to implement!”
Software developers hear statements like this more than about half a million times over their career. It raises my eyebrows every time I hear it, typically giving me a little chuckle inside. In all honesty, it is not a surprise that those kinds of inquiries come up and that they come up as often as they do. After all, these queries come from people that do not code so, from their perspective, the questions seem legitimate.
Errors, Intent and Responsive Address Validation
Fundamentally, these are legitimate questions. The misconceptions that trigger this type of confusion often stem from how well humans can quickly find patterns, errors and solutions. So rapidly, in fact, many problems appear to have “fast” or “obvious” solutions.
For example, to us, it may seem obvious that in our Service Objects address the typo “Cta Street” should be “Cota Street” or “Santa Barbra” should be “Santa Barbara.” These errors are relatively easy to identify, fix and classify right? For humans, the answer is yes. For a computer, on the other hand, the answer is, well…maybe.
At its heart, the issue involves underlying questions about conceptual intent and programming capabilities. For example, when the name of a city is corrected, what does that mean for the data related to the corresponding physical address? Does St. Louis being changed to Saint Louis maintain the fidelity of the locational intent? What about changing Santa Barbara to nearby Goleta? Would these solutions fall within what would be expected behavior?
While both actions result in changes to a piece of information, each solution is based on a different procedure. The first follows a standardized correction of the name of a specific location, which is a type of change to the input. The second, on the other hand, signifies a change in the place itself.
Variations on a Standard: Address Line 2
When it comes to address validation, there are more than enough address variations to examine that constitute a standard address format, and that’s just talking about Address Line 1. Though Address Line 2 is not a standard address field, it has been a custom to see that field in one of it’s many variations on forms when we fill out our address.
Address Line 2 has often left users confused as to what information should be included in that field. While many argue Address Line 2 is designed for apartment numbers, suites, and similar secondary information, there is no consensus. In fact, the USPS does not recognize Address Line 2 as a standard address field.
Reactive Address Verification
In practice, the field is often used for apartment and suite numbers, but also for other details like ‘care of’ or to give additional information to the mail delivery person. Almost anything can go into Address Line 2, and increasingly, people expect Address Line 2 data to be handled as part of the entire address validation protocol.
Ultimately, this field adds a significant layer of complexity to an address validation solution. Take for instance the scenario where someone enters “Apt 2 A C O Sally” on Address Line 2. Typically, someone would not enter the data that way, but you may be surprised how often something like this does come up. Visually, we can easily identify the intention of the data. An address validation process, on the other hand, will find identification and categorization of this information difficult. For example, what does “Apt 2 A C O Sally” signify? Is it Apt 2A, Care of Sally? Or is just Apt 2? Furthermore, once we identify the “Care Of” details, does that information need to be preserved on the output?
Standardized Solutions and a Custom Fix
In some situations, Service Objects can create a solution capable of handling the complexities of multiple address data inputs beyond the standard format. In other instances, the best result is a happy medium. Sometimes a specific solution can be tailored to a particular client based on their individual needs. Always, our updates can fine-tune operations and benefit all of our clients.
We use our extensive validation knowledge and industry standards and expectations to help govern which approach we take. Situations like these represent what our teams look at all the time, and we are always finding ways to make improvements. Our services are based on almost 20 years of experience.
When we update logic in the system, we often walk a fine line between what the code should do versus what it already does. We always want to improve our processes without negatively impacting clients already used to expected behavior. Improvements capable of changing the expected results for current users will often be bundled up in a new version, but usually, we can find ways to update current versions, so clients always have the latest and greatest option without needing to make any changes.
As we know, the devil is in the details. By drilling down to the smallest and most incremental element of an address input, Service Objects provides the highest level of data verification and address validation services. In fact, our focus on details allows us to be experts in the validation services field, so your organization doesn’t have to be.
