Anyway, one of our customers - representing a company in Germany I think - filed a bug report that said something like "Weather module hasn't updated since January". They'd been going to their fancy intranet home page and seeing the same weather for months at a time.

And this bug report just sat there. For a mixture of technical and political reasons, there seemed to be nobody in the European office able to pick up this report and do anything meaningful with it. We knew about it, we knew that what we were serving to paying customers was hopeless, but we somehow couldn't get our hooks into the right point in the Weather feed to figure out where it was going wrong. Or, collectively, we didn't care enough.

There were various technical and structural factors making it difficult to fix. Weather feeds were known to be problematic (still are I guess) and this code would have been surprisingly low-level C/C++ with custom serialisations and limited logging. Structurally there were problems in getting attention from a team in California to support a problem experienced by a different team in London, especially since it affected relatively few users - a tension in supporting paid products in a company that is focused on non-paying users at far greater scale.

(I am assuming this bug would have needed some actual development work - I don't recall, but I think we were familiar enough with common ops problems that it wasn't just a question of kicking one of our own feed servers.)

But I do think there was an issue about lack of concern - at heart we didn't have enough confidence in our own product to motivate the personal pain of working through these problems and getting them solved. I think that, if you had gathered us together and asked our collective opinion, we would have suggested that this customer would be better off not using our product at all - it simply wasn't ever likely to be good enough. Once you reach that way of thinking about your own product, it becomes extremely hard to countenance fixing the most difficult problems with it.

I've sent feedback and error reports about this repeatedly, and even had a friend that knows someone that works on Maps pass it on to them directly. It's never been fixed, and I've basically just given up on it at this point. It's really shown me how impossible it is to get any kind of support from Google for even an extremely obvious, straightforward issue.

In the end what worked for me was registering as google maps client/customer, reproducing the issue via API, and then reporting it as an API issue. The underlaying data was fixed within a day or two, and I got my emails answered by google engineer within (literally) minutes.

I recently moved, and found out that virtually every single web site from my credit cards to my bank to the library uses Google to verify address entry on the fly. The problem is that Google's database entry for my address is wrong. So any time I try to enter the address "123 Oak Street, Apartment Q" Google unhelpfully corrects it on the fly to "Oak Street, Suite 1." No amount of keyboard jockeying can override Google's on-the-fly autocorrection.

The solution I eventually came up with was to turn off javascript, then enter my correct address, then turn javascript back on to finish the rest of the form.

Of course, there's no way to contact Google about its error. Maybe in Google Maps? I dunno. How do you find an address that Google Maps doesn't know to tell it that the address it has is wrong?

(please do not take this as an endorsement of google maps support, merely an anecdote of what did work for me that I hope might help you)

With Apple, I've submitted perhaps 5 corrections for 5 different (usually minor) problems in 5 years. Problems like a place claims to take Apple Pay when it doesn't. Or the actual place is across the street from where Maps claims it is.

In each case, Apple sends back a notification within 2-3 weeks saying they've fixed the problem, and when I've checked, it has always been resolved. Pretty happy with the service.

"What is the weather report for today/this week?" is a more accurate question, despite an annoying amount of verbosity. But answers are still given relatively. "Cloudy" could be an accurate answer, for now. But it will be "Sunny" this afternoon.

Some people will prefer a one word answer to "What's the weather?". Others, will want an hourly breakdown of the day displayed on their screen. Others, might prefer a week. It's hard to give an ideal response for every situation.

Ironically, if I say "Hey Siri, weather" I usually get what I need.

Now that you mention it, I find it strange that voice assistants don't give natural responses when they encounter an error. It would make them seem more real, and it would be less frustrating.

When you ask a human what the weather is and they tell you to look outside, you don't try to rephrase the question in a way that will make them give you the right answer, you just realize this is not the way to get an answer and you look for another way.

Maybe this isn't the best way for it to work in this case, since there is a different thing you can ask to get the response you want, but maybe this would make interactions better if, say, the phone can't detect your location. "Where did you want the weather for? I think I'm lost."

Of course, the other problem is that if it gives the same response every time it'll get grating. The hundredth time you hear "Look outside," it has probably lost its charm. I wonder how possible it would be to generate responses that take into account all previous conversations, so that this doesn't happen.

One of my meteorologist friends always answers "What's the weather?" with, "The state of the atmosphere."

The possibilities are endless.

Other times it will tell me the wind speed.

Other times, for the same query, it will tell me the wind speed AND direction, which is what I want.

But it's always random what I get: wind speed, wind direction, a combination of both, or (occasionally) the definition of wind.

I wasn't aware of any other occurrences.

I think that pretty much any assumption we're making about strict hierarchy are bound to be broken at some point.