This is where most of the "falsehoods programmers believe" articles fall flat.
The thing to do is not try to design a single form that accommodates every possible address or name or whatever. The thing to do is examine your use case, design a form that works for, say, 99.9% or more of the people you want it to reach, and then if you really want to get the last 0.1% have someone who can do customer service and has access to a freeform text box into which they -- not the end user -- will enter the information.
Because when you get right down to it, the freeform text box is the only thing that accepts 100% of valid addresses (or valid names, or whatever). But it also necessarily accepts a ton of invalid ones, too, and so it causes more trouble for the common cases than it saves in the uncommon ones.
So maybe have a typical address form and add a checkbox labelled "My address doesn't fit the required format" that would replace your usual form with a freeform text field?
I've found that if you have authoritative addressing data for your target market(s), a search/autocomplete field is a great alternative to the multi-field form being talked about in this discussion. Having access to that sort of data is, of course, a pretty big caveat as much of it is currently proprietary but efforts are being made globally to address (couldn't resist!) this (e.g. http://openaddresses.io, http://alpha.openaddressesuk.org).
"Punt and let customer support handle it" is a pretty lazy solution, in my view. Additionally, what a developer might think of as a "99.9%" solution is more often than not a 99% solution, or a 90% solution. With enough customers, dealing with everyone who can't use your slapped-together form will be more expensive than doing it right.
Software doesn't become great by assuming someone else will handle the edge cases and details, although you may get away with selling it for a while until your user base grows.
With enough customers, dealing with everyone who can't use your slapped-together form will be more expensive than doing it right.
The way you write shows some deep assumptions: that this is a case of "slapped-together" vs. "great" software, for example. And those assumptions are, I'd assert, counterproductive to the discussion at hand.
The comment I was replying to actually was a real-world example of what you're missing, namely that this is a trade-off. Every time you support another 0.0001% of corner cases, you're increasing the surface area of potential failures for other cases. And since the other cases are far more common, they're going to bite you more often.
Supporting the most common cases, to a 99.9% or so level, directly and then having an escape hatch for the rest is not "slapped together" -- it's deliberate design which takes the problem and the cost/benefit of different solutions into account. It's also, from that perspective, almost certainly the correct design.
And yet it gets blasted repeatedly in articles like the OP here, which assume that the only possible reason for such design is ignorance/incompetence on the part of the developer. That simply is not true, and you should stop implicitly buying into that (it's another assumption that's hidden in the way you write).
Except, in this scenario, it's relatively easy to come up with a good 99.9% solution:
Seven text fields will cover greater than 99.9% of users:
Name
Address Line 1
Address Line 2
City
State
Country
Postal Code
So much of that article discussed stuff that was irrelevant - Live in Singapore? Great, just fill in Singapore, Singapore, Singapore. I've done that on many, many sites and it's always worked fine. Don't have a postal code in Ireland? Most people there learn to try EIRE or 00000.
I think a better article would have been:
"Here are the scenarios in which the 7-text address system doesn't work, and how you can make it better." - But I couldn't find anything that suggested it wouldn't work just fine.
My country unfortunately doesn't fit that scenario. Here in the UAE there is no residential postal delivery, so if you want to receive letters you have them sent to a PO Box. Most people usually use their office's, but I have my own. That means you can reach me with simply:
PO Box XXXX
Dubai
UAE
For sending parcels to be delivered by a courier you can include a physical address, however most streets here don't have names (and even if they do people have no idea what they are) so people go by directions. Which means something like:
Flat XXXX
Building Name next to / opposite / near Landmark
Area Name
In most cases it's best to include a phone number so the courier can phone for directions if they get lost (without street names it's easy), and of course everyone requires a name even though I'm the only person living here and using this PO Box. That means my 'full address' ends up being:
Name Surname
Tel: 05XXXXXXXX
Flat XXXX, Building Name
Next To Landmark
Area Name
PO Box XXXX
Dubai
UAE
In most cases that never fully fits in the length of the fields, or they do something silly like requiring a postcode but limiting it to 5 digits (luckily my PO Box number is only 4 digits in length, but in reality they are [0-9]*). Anything I order from eBay has "NOTPROVIDED" on it as I left out an optional field they think should always be included :D
Edit: Area names have their own fun: There is a road going from one end of the country to the other which in Dubai is called Sheikh Zayed Road (it has a number and different names in other emirates :D), but that is also the name of an area along part of the road.
I think this is the key point. Sure, you can come up with some clever and unique system to accommodate the one percent of your user base who isnt well served by standard forms, but that 1% is already used to adapting their unique information into a standard format.
Web forms for things like name and address are a sort of ad-hoc standardization of a nonstandard data type.
The main thing is not to make every field required. I've got nothing meaningful to fill in at state, nor at address line 2. Too many sites make too many false assumptions about addresses.
I have never seen anywhere require "Address Line 2." It's only used as a specifier to the address when there are multiple units at the address (office buildings, apartments, and the like).
Great software is that which solves your business problem.
If not "punt to a human", what's the solution? We've already seen that giving users a free-form text box is a cure worse than the disease. Do you analyze every country's address scheme and make a dynamic form that covers all the cases? (worse IMO - it's not going to cover all the cases, and it's going to be even more infuriating for users when it goes wrong. See the Jersey example in another comment) Some wizard solution that I can't think of? Saying this approach is "lazy" is all well and good, but do you have a positive proposal?
The thing to do is not try to design a single form that accommodates every possible address or name or whatever. The thing to do is examine your use case, design a form that works for, say, 99.9% or more of the people you want it to reach, and then if you really want to get the last 0.1% have someone who can do customer service and has access to a freeform text box into which they -- not the end user -- will enter the information.
Because when you get right down to it, the freeform text box is the only thing that accepts 100% of valid addresses (or valid names, or whatever). But it also necessarily accepts a ton of invalid ones, too, and so it causes more trouble for the common cases than it saves in the uncommon ones.