Live data from Hacker News

Falsehoods programmers believe about addresses

mjt.me.uk

71–80 of 150 posts

Re: Falsehoods programmers believe about addresses

#71

I read this article a long time ago and I took it seriously. So instead of asking for address, postal/zip code, city, state/province, I just put up a big text area labeled "Full address" so that people have complete freedom about what to fill in. 80% of the users ended up only filling in their street address, not their postal/zip code, city and state/province, even though they're from countries where (most?) addresse…

[deleted]

Re: Falsehoods programmers believe about addresses

#72

Earlier quoted context omitted.

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 acc…

"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 a…

Sometimes this sort of "lazy" is exactly what people mean when they talk about avoiding premature optimization.

Re: Falsehoods programmers believe about addresses

#73

Earlier quoted context omitted.

even using GPS coordinates How can GPS coordinates be ambiguous? I can see different units of measure/notations being used, and the accuracy might be a problem for extremely close addresses, but wasn't it the point of GPS to provide an exact reference for any point on the planet?

GPS coordinates don't generally include altitude, correct? If he's in a six-floor apartment, how could GPS define which floor he's in?

Then the full name should be anough to determine the floor. More problematic though is the inaccuracy of GPS. Where I live, my smartphone's GPS encircles 3 buildings.

Re: Falsehoods programmers believe about addresses

#74

Earlier quoted context omitted.

It was a form for signing an agreement. If they don't fill in their full address then the contract may not be legally binding.

Simple clerical errors rarely invalidate a contract. I'm not a lawyer though so I don't actually know. I would have done address line 1, address line 2, line3, etc. I think people got confused by your form because they are used to typing in 1234 Sample Street expecting to be asked the rest of the information further down. The other option would be on form submit to show what they have put in and say "make sure this i…

> Simple clerical errors rarely invalidate a contract. I'm not a lawyer though so I don't actually know.

We need a name for this.

Re: Falsehoods programmers believe about addresses

#75

Earlier quoted context omitted.

Simple clerical errors rarely invalidate a contract. I'm not a lawyer though so I don't actually know. I would have done address line 1, address line 2, line3, etc. I think people got confused by your form because they are used to typing in 1234 Sample Street expecting to be asked the rest of the information further down. The other option would be on form submit to show what they have put in and say "make sure this i…

Don't know about the US, but here in the UK having an incorrect address in a contract may make it trickier to enforce a court decision against a company as certain kinds of documents used in the court process are only valid if served to the Registered Office of the company.

Well, if putting down the wrong address on a contract is enough to invalidate the contract, then people would be "accidentally" fudging their addresses all the time. :)

Really, I am no legal expert but I did once sue someone in small claims court. They wanted to know what I did to verify the other party's address, not just taking their word for it.

Re: Falsehoods programmers believe about addresses

#76
post #70
post #63

A falsehood only distantly alluded to: That people have addresses at all, or can describe their residence in an unambiguous or clear way (even using GPS coordinates). I used to live in a place I couldn't even remotely give directions to. It was deep within a neighborhood of a poorer country, none of the streets had names, none of the buildings are numbered. I lived in an building where none of the apartments had numb…

Furthermore, just because you don't have an address doesn't mean you can't receive mail! At least as recently as a few decades ago, there were rural communities in the US where nobody had a street address; the postal service knew where everybody lived and would deliver mail given just a name and town. I'm not sure whether this arrangement still exists in the US, but I'm pretty sure it still does in Ireland and probab…

It also works in Austria! I once got a postcard with just my name and town on it (sender didn't know address or post code).

Re: Falsehoods programmers believe about addresses

#77
When I moved to London and opened up a Lloyds Bank account (then Lloyds TSB), I was confused to find they did not consider my office postcode W1F 7RB valid. I poked at it a bit and found some programmer assumed that the first half of a UK postcode was \w+\d+. The hilarious part was the branch I was opening an account at was in W1S, so their form wouldn't even take their own postcode.

Re: Falsehoods programmers believe about addresses

#78
post #55

Earlier quoted context omitted.

Bad mistake you get a metric fuck ton of shit in your data that way. You should always police your input data properly one big text field is lazy programming that leads to a big technical debt later on. And yes that does mean handling apostrophes and all those other edge cases properly.

Name of recipient, state/province/etc., postal code and country, maybe. But for the rest, that bit (at least in the UK) that goes in the middle... what policing can you do? That part is just a text blob. You can't do much meaningful with it except for showing it to somebody (e.g., on a label affixed to the package you're sending) and have them figure it out.

Well sure, once you've separated name and country and postal code you've already pulled out most of the data.

The blob has been tamed to 1-2 lines, and you're probably best off giving 'line 1' 'line 2' 'line 3' fields. At this point the chance of confusion is minimal, even if you can't validate very well.

Re: Falsehoods programmers believe about addresses

#79
post #55

Earlier quoted context omitted.

Bad mistake you get a metric fuck ton of shit in your data that way. You should always police your input data properly one big text field is lazy programming that leads to a big technical debt later on. And yes that does mean handling apostrophes and all those other edge cases properly.

Name of recipient, state/province/etc., postal code and country, maybe. But for the rest, that bit (at least in the UK) that goes in the middle... what policing can you do? That part is just a text blob. You can't do much meaningful with it except for showing it to somebody (e.g., on a label affixed to the package you're sending) and have them figure it out.

make sure its valid text - make sure you handle all the high asci characters and do something sensible with non Latin text.

I once spent the best part of a day tracking down a problem with a single bad address for a major UK directory some how some one had entered an address in Egypt in Arabic.

Re: Falsehoods programmers believe about addresses

#80
This hit home for me as a couple of months ago we faced the choice between continuing to develop a parser-based approach to location extraction from free text, or moving to an entity extraction and search approach, i.e. geotagging or geocoding. Notably we were just trying to get city and state, and even limiting ourselves to the U.S. the combinations we were seeing made parsing seem like a game of increasing complexity delivering diminishing returns. We ultimately went with a search-base approach and it's been working much better and is more tolerant of format variations.
Post reply on HN