5 ms·

Not my area of expertise, but is this not a form of perfectionist problem? I mean, most places have a clear and simple address. For the rest, either a human can

Not my area of expertise, but is this not a form of perfectionist problem? I mean, most places have a clear and simple address. For the rest, either a human can solve it, or we can make a few examples and let an AI do the work. We can go back to them later and revise them if we need to. Addresses don't change often, so I think things can stay the same for a long time. Except for emergency dispatch and a few high-profile use cases, you can have a good enough address to let the user find its neighbourhood. But they still have the GPS or other form of address coding, so they can find the exact location easily. I'd say 99.9% of the cases are like that. The rest can be solved quickly by looking at the map!

edent 1y ago
I am deeply guilty of being a perfectionist! Ultimately, I just want something which is a nice balance between being useful for a human and not so long that it is overwhelming.
- curiousObject 1y ago
  You’re the author? The final step in the process “Wait for complaints” seems like a smart acceptance of the “perfect is the enemy of good” challenge Publish and be damned, or as we say now: Move fast and break things
smitty1e 1y ago
I was going to take this tack. 80% of the problem is just transforming floating point coordinates into API calls. Getting to something useful with it is the hard 20%, and it will be a diminishing returns problem after that. While not anybody's LLM proponent, that last mile might be a good AI application.
ryandrake 1y ago
You can call it perfectionism or you can call it "doing it right." I think this gets at a fundamental difference in philosophy among [software] engineers: We have a problem with a lot of edge cases, where a "good enough" solution can be done quickly. What do we do? There's a class of engineers who say 1. Do the "good enough" solution and ignore/error on the edge cases--we'll fix them later somehow (may or may not have an actual plan to do this). And there's a class of engineers who say 2. We cannot solve this problem correctly yet and need more research and better data. Unfortunately (in my view), group #1 is making all the products and is responsible for the majority of applications of technology that get deployed. Obviously this is the case because they will take on projects that group #2 cannot, and have no compunction against shipping them. And we can see the results with our eyes. Terrible software that constantly underestimates the number and frequency of these "edge cases" and defects. Terrible software that still requires the user to do legwork in many cases because the developers made an incorrect assumption or had bad input data. AI is making this problem even worse, because now we don't even know what the systems can and cannot do. LLMs nondeterministically fail in ways that sometimes can't even be directly corrected with code, and all engineering can do is stochastically fix defects by "training with better models." I don't know how we get out of this: Every company is understandably biased towards "doing now" rather than "waiting" to research more and make a better product, and the doers outcompete the researchers.
- sbarre 1y ago
  > Unfortunately (in my view), group #1 is making all the products and is responsible for the majority of applications of technology that get deployed. This is an interesting take, and I think I see where you're coming from.. My first thought on "why" is that so many products today are free to the user, meaning the money is made elsewhere, and so the experience presented to the user can be a lot more imperfect or non-exhaustive than it would otherwise have to be if someone was paying to use that experience. So edge cases can be ignored because really you're looking for a critical mass of eyeballs to sell to advertisers or to harvest usage data from, etc.. If a small portion of your users has a bad time or experiences errors, well, you get what you pay for as they say.. And does that kind of pervasiveness now mean that many engineers think this is just the way to go no matter what?
- e63f67dd-065b 1y ago
  Engineering is about tradeoffs -- are the resources invested in improving a system worth the return of said improvement? We know full well how to build bridges that will last a thousand years, we just choose not to because it's not an effective use of public funds compared to a fifty year bridge. The same applies to software engineering -- each additional edge case you handle increases cost but has diminishing returns. At some point you have to say good enough and ship. The cost of perfection is infinite -- you have finite resources, and a great part of engineering is deciding how to allocate them.
jandrewrogers 1y ago
The update rate for a global map data model, all of which are still woefully incomplete in many contexts, is surprisingly high. The territory underlying the map is a lot less static than people assume. Also, local reality is often much less “regular” than people assume such that a person really can’t figure it out reliably. Currently there are literally thousands of people tasked with incorporating these changes because it has proven to be resistant to automation thus far due to the pervasiveness of edge cases. For your basic global map data model, these are the edge cases that are left after several thousand heuristic and empirically derived rules have been applied. It is a deeply complex data model that changes millions of times a day in unpredictable ways. Unfortunately, many applications are very sensitive to the local accuracy of the model, which is much higher variance than average accuracy. Only trying to be “good enough” in an 80/20 rule sense is the same as “broken”. The updates are also noisy and often contain errors, so the process has to be resilient to those errors. The resistance of the problem to automation and the high rate of change has made it extremely expensive to asymptotically converge on model with consistently acceptable accuracy for the vast majority of applications.
mootothemax 1y ago
> most places have a clear and simple address That depends on your definition of "clear and simple" and "address" :) While a lot boils down to use case - are you trying to navigate somewhere, or link a string to an address? - even figuring out what is an address can be hard work. Is an address the entrance to a building? Or a building that accepts postal deliveries? Is the "shell" of a building that contains a bunch of flats/apartments but doesn't itself have a postal delivery point or bills registered directly to it an address? How about the address the a location was known as 1 year ago? 2 years ago? 10 years ago? Park and other public spaces can be fun; they may have many local names that are completely different to the "official" name - and it's a big "if" whether an official name exists at all. Heck, most _roads_ have a bunch of official names that are anything but the names people refer to them as. I have a screaming obsession with the road directly in front of Buckingham Palace that, despite what you see on Google Maps, is registered as "unnamed road" in all of the official sources. > Addresses don't change often At the individual level, perhaps. In aggregate? Addresses change all the time, sometimes unrecognisably so. City and town boundaries are forever expanding and contracting, and the borders between countries are hardly static either (and if you're ever near the Netherlands / Belgium border, make a quick trip to Baarle-Hertog and enjoy the full madness). Thanks to intercontinental relative movement, the coordinates we log against locations have a limited shelf life too. All of the things I used to think were certain... If someone hasn't done "faleshoods programmers believe about addresses," I think its time might be now! Edit: answering myself with https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...
Beretta_Vexee 1y ago
The author's problem is similar to many real-world business problems. A simple example is directing delivery drivers to the correct entrance of a large site with multiple entrances depending on the type of delivery (mail to door A, van to door B, semi-trailer to door C). Sending a Romanian truck driver to a vague address in Holland such as ‘port terminal B somewhere on road 999’ and leaving him to figure it out for himself is not a solution.

edent 1y ago

I am deeply guilty of being a perfectionist! Ultimately, I just want something which is a nice balance between being useful for a human and not so long that it is overwhelming.

curiousObject 1y ago
You’re the author? The final step in the process “Wait for complaints” seems like a smart acceptance of the “perfect is the enemy of good” challenge Publish and be damned, or as we say now: Move fast and break things

smitty1e 1y ago

I was going to take this tack. 80% of the problem is just transforming floating point coordinates into API calls. Getting to something useful with it is the hard 20%, and it will be a diminishing returns problem after that. While not anybody's LLM proponent, that last mile might be a good AI application.

ryandrake 1y ago

You can call it perfectionism or you can call it "doing it right." I think this gets at a fundamental difference in philosophy among [software] engineers: We have a problem with a lot of edge cases, where a "good enough" solution can be done quickly. What do we do? There's a class of engineers who say 1. Do the "good enough" solution and ignore/error on the edge cases--we'll fix them later somehow (may or may not have an actual plan to do this). And there's a class of engineers who say 2. We cannot solve this problem correctly yet and need more research and better data. Unfortunately (in my view), group #1 is making all the products and is responsible for the majority of applications of technology that get deployed. Obviously this is the case because they will take on projects that group #2 cannot, and have no compunction against shipping them. And we can see the results with our eyes. Terrible software that constantly underestimates the number and frequency of these "edge cases" and defects. Terrible software that still requires the user to do legwork in many cases because the developers made an incorrect assumption or had bad input data. AI is making this problem even worse, because now we don't even know what the systems can and cannot do. LLMs nondeterministically fail in ways that sometimes can't even be directly corrected with code, and all engineering can do is stochastically fix defects by "training with better models." I don't know how we get out of this: Every company is understandably biased towards "doing now" rather than "waiting" to research more and make a better product, and the doers outcompete the researchers.

sbarre 1y ago
> Unfortunately (in my view), group #1 is making all the products and is responsible for the majority of applications of technology that get deployed. This is an interesting take, and I think I see where you're coming from.. My first thought on "why" is that so many products today are free to the user, meaning the money is made elsewhere, and so the experience presented to the user can be a lot more imperfect or non-exhaustive than it would otherwise have to be if someone was paying to use that experience. So edge cases can be ignored because really you're looking for a critical mass of eyeballs to sell to advertisers or to harvest usage data from, etc.. If a small portion of your users has a bad time or experiences errors, well, you get what you pay for as they say.. And does that kind of pervasiveness now mean that many engineers think this is just the way to go no matter what?
e63f67dd-065b 1y ago
Engineering is about tradeoffs -- are the resources invested in improving a system worth the return of said improvement? We know full well how to build bridges that will last a thousand years, we just choose not to because it's not an effective use of public funds compared to a fifty year bridge. The same applies to software engineering -- each additional edge case you handle increases cost but has diminishing returns. At some point you have to say good enough and ship. The cost of perfection is infinite -- you have finite resources, and a great part of engineering is deciding how to allocate them.

jandrewrogers 1y ago

The update rate for a global map data model, all of which are still woefully incomplete in many contexts, is surprisingly high. The territory underlying the map is a lot less static than people assume. Also, local reality is often much less “regular” than people assume such that a person really can’t figure it out reliably. Currently there are literally thousands of people tasked with incorporating these changes because it has proven to be resistant to automation thus far due to the pervasiveness of edge cases. For your basic global map data model, these are the edge cases that are left after several thousand heuristic and empirically derived rules have been applied. It is a deeply complex data model that changes millions of times a day in unpredictable ways. Unfortunately, many applications are very sensitive to the local accuracy of the model, which is much higher variance than average accuracy. Only trying to be “good enough” in an 80/20 rule sense is the same as “broken”. The updates are also noisy and often contain errors, so the process has to be resilient to those errors. The resistance of the problem to automation and the high rate of change has made it extremely expensive to asymptotically converge on model with consistently acceptable accuracy for the vast majority of applications.

mootothemax 1y ago

> most places have a clear and simple address That depends on your definition of "clear and simple" and "address" :) While a lot boils down to use case - are you trying to navigate somewhere, or link a string to an address? - even figuring out what is an address can be hard work. Is an address the entrance to a building? Or a building that accepts postal deliveries? Is the "shell" of a building that contains a bunch of flats/apartments but doesn't itself have a postal delivery point or bills registered directly to it an address? How about the address the a location was known as 1 year ago? 2 years ago? 10 years ago? Park and other public spaces can be fun; they may have many local names that are completely different to the "official" name - and it's a big "if" whether an official name exists at all. Heck, most _roads_ have a bunch of official names that are anything but the names people refer to them as. I have a screaming obsession with the road directly in front of Buckingham Palace that, despite what you see on Google Maps, is registered as "unnamed road" in all of the official sources. > Addresses don't change often At the individual level, perhaps. In aggregate? Addresses change all the time, sometimes unrecognisably so. City and town boundaries are forever expanding and contracting, and the borders between countries are hardly static either (and if you're ever near the Netherlands / Belgium border, make a quick trip to Baarle-Hertog and enjoy the full madness). Thanks to intercontinental relative movement, the coordinates we log against locations have a limited shelf life too. All of the things I used to think were certain... If someone hasn't done "faleshoods programmers believe about addresses," I think its time might be now! Edit: answering myself with https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...

Beretta_Vexee 1y ago

The author's problem is similar to many real-world business problems. A simple example is directing delivery drivers to the correct entrance of a large site with multiple entrances depending on the type of delivery (mail to door A, van to door B, semi-trailer to door C). Sending a Romanian truck driver to a vague address in Holland such as ‘port terminal B somewhere on road 999’ and leaving him to figure it out for himself is not a solution.