Hacker News Reader

The counter-argument is that we’re (mostly) talking about profitable companies making billions a year, which will be wasting tens or hundreds of millions anyway on unneccessary spending, poor strategic decisions, and other standard corporate cash sinks.

Why not gain reputation and good will by making users happy and deliberately cultivating a reputation for low-frustration, responsive, thoughtful and reliable products?

Of course this is the opposite of “Get shit out fast, fix it later” and would surely be very boring to work on.

But even so.

The problem is that you can't even identify, much less stop, the cash sinks - nobody seems to be able to do it in any sort of large corporation (or any other sort of organisation). Fixing some random bug that you have no impact numbers for therefore has to compete with the sexy new six-month cash sink that someone thinks will bump stats across the board. "Perfect is the enemy of good" seems to be the mantra, which would be better written as "lazy is the enemy of good." Can we not agree that this is a bullshit saying, and that nobody ever argued for actual perfection? We just have different ideas of what constitutes good (or profitable) software.

> The reason for pretty much any bug found in software driven by a huge company is that there is a large disconnect between fixing bugs and profit.

Exactly. The answer to any complaint like the one described in this article (and I have similar ones about my phone all the time) is "how much would you be willing to pay to fix this?"

Of course, it doesn't help that, even if I were willing to pay to fix this, I have no way of doing so; even if, say, 100,000 or 100 million users would all be willing to pay to fix it, so that the amount in play might actually be enough to compensate a developer to do the work, we have no way of coordinating such a payment. That's not just because the companies involved are large; it's because the software running on, say, my phone is a cost center to begin with, not a profit center. The profits come from locking users into multi-year contracts, and "too many bugs/misfeatures in the software on the phone" is so far down the list of things the phone provider is worried about people switching for that there is no motivation to spend money on it.

> which might cause a bug like this to cost tens of thousands of company dollars to fix, while the benefit to each user (and therefore the company) would be a tiny fraction of a cent

But if there are 100 million users, that might still work out to a tidy profit--if the users could somehow coordinate the payment, and convince the company that the alternative to accepting the payment and fixing the problem was that all 100 million of them switch providers. In the real world, of course, this will never happen.

>Of course, it doesn't help that, even if I were willing to pay to fix this, I have no way of doing so; even if, say, 100,000 or 100 million users would all be willing to pay to fix it, so that the amount in play might actually be enough to compensate a developer to do the work, we have no way of coordinating such a payment.

No, but we can always go and use another app that doesn't have as many problems.

> we can always go and use another app that doesn't have as many problems

What other app? What apps don't have random bugs or obviously insane behavior popping up when you least expect it?

There is a tipping point. Just ask TSB. At some point you need to clean up your tech debt or you risk systemic failure.

TSB's systemic failure was a result of trying to clean up their tech debt (and dependency on Lloyds' systems), though -- the old systems were working fine for them (and continue to work fine for Lloyds), not falling over all the time.

This isn't a bug. Recommendations are just hard.

He's trivializing it, but specifically mentions that including one 5.7 miles away would be fine. And then promptly says because he visited it before.

That's some complicated intelligence and pattern matching that he's asking for. What exactly should it be ranking by? Proximity and popularity and traffic density and Google rating and awhole load of other things.

The rules that Google apply obviously work for some scenarios, but not this one. Could it be better, obviously, but that's not a bug.

I feel that Google Maps search quality has gone down in the past few years. Sometimes searching "Coffee shops" will not show anything within a mile and I have to reposition, press "Search this area" and then it will show the Starbucks a block away.

Probably still better than Apple, which pointed me to a 19-hours-away store when asking for "directions to Albertsons" a couple years ago: https://i.imgur.com/jSCrToj.jpg

>This isn't a bug. Recommendations are just hard.

What is hard about ordering a bloody list of places by distance?

>He's trivializing it, but specifically mentions that including one 5.7 miles away would be fine. And then promptly says because he visited it before.

Well, they could first add the bloody sorting, then we can think about whether they should mark or prioritize previously visited places (which itself does not take any "complicated intelligence and pattern matching" -- it's just persisting visited places and consulting their list).

I like you feigned exasperation at the simplicity of it all and then immediately noticed one of many many complicating factors.

My point is that all the "complicating factors" are still trivial -- each alone, or put together.

My second point is also that even if they weren't (for some exotic cases) , the most common cases and sane defaults, remain trivial -- and anything else could be relegated to settings and the like.

My third point is also that no matter how easy or hard the complicating factors, a screen like the one shown by the poster, is an utter failure.

To continue on this 2nd and 3rd point, it's like people are trying to defend Clippy, the office assistant, by saying that "AI is hard".

It might be, but getting Clippy out of my bloody monitor and not having it disturb me when I try to compose a Word document, is very easy. MS could always do that (and that's what they ended up doing).

For location based stuff it seems pretty logical functionality to at offer the ability to sort results by travel time or at least distance. I still have to log into god-awful store websites and use their store locators because they'll give me the information I need.

Seems like a case of adding "ORDER BY number_of_previous_visits, distance" to a SQL query...

Having actually programmed search functionality like this I can assure you, it's really not. That's what you start with. Even if you put aside that distance is something that has to be calculated through triangulation as many systems now include that.

Especially when you add in rankings, you start having to think about sorting by multiple layers, circles of distance with ranking sorted by that.

So the really good match 20 miles away is shown lower than the pretty good match 5 miles away, but they're both shown above the bad match 7 miles away.

And that's before you add categories, past history, any paid ranking, etc. And then the queries get really expensive and you've got to decide what to fudge or not to keep the system responsive and stop your search system eating all your CPU.

And you can bet people will still find scenarios where they'll say "why's it doing this? I'd expect the order to be different".

This is pattern matching and value assignment, something humans are amazing at and computers aren't.

>Having actually programmed search functionality like this I can assure you, it's really not. That's what you start with. Even if you put aside that distance is something that has to be calculated through triangulation as many systems now include that.

It already prints a distance.

It could use that. Or, if it is some kind of point to point distance, it could calculate a driving distance and use that if it wanted to be extra smart.

Add the type of place it shows, and be done with it.

>Especially when you add in rankings, you start having to think about sorting by multiple layers, circles of distance with ranking sorted by that.

We've been doing multiple criteria sorting for millennia. It's not rocket science either.

>So the really good match 20 miles away is shown lower than the pretty good match 5 miles away, but they're both shown above the bad match 7 miles away.

Why is one "really good" and the other's (that are also of the same store) not? They are bloody stores of a franchize.

Don't try to be clever and define what's "good" and just show them to me sorted by distance AND type (in case there's a city called that too or something). End of story.

>And you can bet people will still find scenarios where they'll say "why's it doing this? I'd expect the order to be different".

People might or might not say anything. But way fewer will be confused by a distance sorted list + an indication of what the item they saw is (store, city, village etc), than with this clusterfuck of a result.

There's a massive difference to printing 10 distances from your result set, and calculating 10 million. I'm not sure why you had to exaggerate "millennia".

How does a computer know that searching "Wawa" means you want the store and not the town? You haven't even considered that. It's a search term.

And a really good system would clearly takes a load of things you're not considering into account, relevance, rank, personal relevance, historical relevance age, etc. A really good system might even helpfully try to include traffic density, how busy a store was, etc. What if all the stores near him have 1 star google reviews? What if some of those Wawas are paying for adverts and some aren't? What if some of them have opening times set up, and some don't?

As I say, their ranking system might be working great for other things, but something like this it spits out crap.

>There's a massive difference to printing 10 distances from your result set, and calculating 10 million.

Well, no reason to calculate 10 million. If another way to select a list of top suggestions to show is less costly, you can just calculate the distance for the existing suggestions they're already about to show - and then show them sorted by the distance).

Having the unknown criteria they used to pick the suggestions reflected in the order they show them is not useful to anyone though.

>I'm not sure why you had to exaggerate "millennia".

Not exaggerating -- pointing to the fact that we know techniques to do it, and we have been doing it (obviously manually before computers) for millennia.

>How does a computer know that searching "Wawa" means you want the store and not the town? You haven't even considered that.

I did, and I mention it in 2 places in my response above: they could either sort all by distance and display what each entry is next to it (e.g. town, store, etc), or give sorted lists for different types of results (e.g. locations vs businesses).

>And a really good system would clearly takes a load of things you're not considering into account, relevance, rank, personal relevance, historical relevance age, etc.

Whatever the above system "took into account" it failed. And it's a case that's common to 99% of the population (search for a business). Searching for a location is another 99% common case.

Historical relevance and age? Who cares besides tourists (and even them, when they're not searching for a location or a business but for sightseeing)? A system should have sane defaults and hide those other things under user enabled search/sort criteria.