It's a problem with many developers. They think that because there can be a root cause analysis, they didn't fuck up.
But there are times when something simply shouldn't be, definitionally. As in, if X happens, it doesn't matter what the root cause analysis is, something is wrong.
To give a real life example, if you're driving drunk, the events and reasons leading up to the act don't really matter. They're not without value, but they're not important for determining that someone fucked up.
This is what the poster you're responding to is saying. That the problems are so goddamned egregious that they simply shouldn't be. It's not up to the aforementioned poster to fix the problems, it's up to the companies in question wanting to be better.
Fair point, but that's obviously not true. All evidence we have points to both amazon and google following excelent software development practices. They are even drivers of good practices in certain parts. So, we'd need stronger evidence to show that they are not doing their due diligence before releasing new versions. I'd say that releasing software without tests, code review and incremental rollout would be akin to drunk driving. However, I believe they do all of that and more.
Moreover, I don't know about the many developers you have experience with, but if the developer considers the behaviour to be a bug, I have a hard time believing they don't consider the behaviour to be a failure (ie. someone made a mistake somewhere). Though, I can definitely see people shifting the responsability to someone else, specially if there's a blame culture in place. Obviously, that's easier to do once you know the root cause. However, a company will be better off by putting solid QA practices in place and measuring "fuck ups" as a decrease in productivity instead of measuring it as the number of times each developer break production.
Maybe the issue they are doing too much dev and less contact with real users. You can unit test all your code but you can't cover all possible real data, so you need to accept user feedback. Sometime ago in one of our products there was an issue with RTL languages, as a developer it was first time I hit this concept, I got the report, I informed myself, I fixed the issue,the ticket was closed,the user was happy. In this case it is clear the developer assumed that they can always find someone picture, the assumption is wrong but probably all the TDD and good dev practices won't catch this issue until someone listens to the user reports.
I think they are passive aggressively telling you something essentially. The public complaints bin would wind up such a useless cesspool of entitled idiots and nuts complaining about "bias" because it doesn't conform to their warped worldview or issues that aren't even theirs like slow boot times. Actually processing that would be a massive sisphyean task with little actual gains from it. You know the "fire your bad 20% of customers that take 80% of your time" advice? Their numbers at large are looking far worse so just didn't hire them preemptively essentially. Strategically it makes no sense to do so.
Google does offer a feedback button in the knowledge panel. However, I assume they are unlikely to take any actions unless there's at least a certain amount of agreeing feedback.
I am wondering if they also put an algorithm to decide when "a certain amount of agreeing feedback" is reached. But TBH compared to other search engines Google is much better in general, my doubts are on the "summary" Google is doing presenting stuff as fact instead to just link you to the source directly.
^ this is exactly the attitude I'm referring to. Let me give you an anecdote to further illustrate.
Last friday my internet went out (Cox) and I called into support. The first thing the guy told me? My equipment is too old.
This is simply unacceptable as a reason why my internet stopped working at 6 in the morning. I suspect it was an attempt to upsell me a new modem, but I have a docsys 3 that's under 5 years old. It doesn't matter. Any series of events that results in technical support leading with blaming "old equipment" on the outage is wrong, period. Maybe the equipment went bad, it happens, but that's not what you lead with. Certainly not before trouble shooting.
This is what I mean when I say "definitionally". It doesn't matter what their motivation is. It doesn't matter if it's possible that my equipment died. That employee fucked up.
This isn't about technical excellence or software practices. This is about decision making.
I'm not sure if that employee fucked up. That may be company policy. Support people usually follow a script and they very rarely venture much beyond that. Partially because they lack technical knowledge and partially because it could actually get them in trouble. If I understand it correctly and you were calling your ISP at 6am, I don't think the person you were talking to was a developer. That said, I have no expertise in customer relations, so I wouldn't know if they were following good practices or not in that instance.
I get your point that people make bad decisions, but in software development, those bad decisions shouldn't break the user experience, but decrease the developer's (and/or the team's) productivity instead. Doing root cause analysis is part of the process to achieve that, as it can give insight on how to avoid that class of problems in future. That said, if someone is not doing a good job, they'd hopefully figure it out by themselves, but constructive feedback can also go a long way. Ultimately, if you have a good process in place, it should help you to make an educated assessment of who is underperforming (eg.: their PRs take very long to merge, they are full of beginner's mistakes, their code is never properly tested, their releases are always rolled back a few times until they get it right, etc). All of that without playing the blame game on the (hopefully) rare ocasion that a major bug is found in production.
To a user "The employee fucked up" and "Management fucked up" and "The developers fucked up" are indistinguishable.
Your blame-free production line won't help you if you're making the wrong thing and/or your UX doesn't help the user.
Example: someone at Google decided that if you make a general area-based query - e.g. vets in SF - street view is disabled.
It doesn't matter why they made that decision. To a user, it's an annoying inconvenience. The fact there may - or may not be - some kind of management rationale doesn't make it less annoying or less inconvenient. Nor does the fact that the code doubtless passes the tests it's designed to pass.
The same applies to Amazon's search options. I don't want to see results for 1.5TB external hard drives or any internal drives at all if I search for "external hard drive 12TB". I also don't want fake reviews, or reviews for unrelated products.
I don't want my own videos with my own music hit with fraudulent copyright claims when I upload them to YouTube. Especially if "my own music" is white noise. [1]
I don't want to have to deal with bugs like Heartbleed, Meltdown, or Spectre. I don't want Excel in Office 365 to fail to respond to double-click select. I don't want my card to be declined for no reason when I'm buying groceries.
I don't want the airliner I'm on to crash because management cut corners.
And so on.
Some of these issues are serious, some are less serious. But what's lacking is seriousness across the industry as a whole. There's an underlying attitude that software is either an annoying cost which can be pared to the bone, or a financial optimisation process, or an interesting puzzle to tinker with. And there seems to be too little deep understanding that it exists outside of a laptop screen, and when it fucks up it causes very real issues for very real people.
> Your blame-free production line won't help you if you're making the wrong thing and/or your UX doesn't help the user.
Blaming someone will not help either. As you said, the user doesn't care who fucked up.
Some of the problems you listed are still open research areas, so I wouldn't call not solving it lack of seriousness. And for the street view thing, given that there's no clear right or wrong, the best they could do is look at the data and see which approach seem to improve the user experience. I hope they've done that, but I don't know.
Then, there are bugs in excel, online shopping, aeroplane systems. Maybe those would be explained as a lack of seriousness, but I don't see how blaming someone would help avoiding those issues.
Finally, there's the recent intel/amd bugs. They were out there for a long time and it took quite a bit of time and ingenuity to find that there was a security flaw there. I think we can hardly classify that as lack of seriousness or understanding that it can have bad effects to people's lives.
This is probably going to come across rude, but I feel like it needs to be said.
nothing in your post was really relevant to this discussion. The fact that it may have been a company policy or that the person wasn't a developer is completely irrelevant to the larger idea. It's literally missing the forest for the trees.
I've been doing software dev for over 20 years and one of the things I'm known for is building very stable systems. Part of the way I do this is by not allowing myself to use these sorts of things as a defense.
When designing and/or building a system I ask: What should not be? Then I build the system to actively look for those situations. Put another way, I don't build systems with the assumption that there are no bugs. Too many developers push the responsibility outside of themselves. As if bugs are inevitable, therefore the fallout from bugs is inevitable. You just do a root cause analysis and move on rather than asking what you could have done differently to avoid the fallout.
I've lost count of the number of times systems I've built have actively refused to do something and then sent out a notification explaining why.
My point here is that you're doing yourself a disservice by insisting that root cause analysis should be enough. Yes it's important, but it's not enough. Some things simply should not be, and they're avoidable.
The problem is that many companies don't really care.
I don't think it's rude to point out someone is missing the point, though I can see why you're considering that given the overall aggressive tone of your messages. Let's backtrack, then. My main point is that scolding an individual for a problem in production is not going to improve the quality of the software produced by a company at all. Do you disagree with that?
Hm, then is your point that many developers become careless while programming because they are in an environment with safeguards in place to avoid screw ups?
But there are times when something simply shouldn't be, definitionally. As in, if X happens, it doesn't matter what the root cause analysis is, something is wrong.
To give a real life example, if you're driving drunk, the events and reasons leading up to the act don't really matter. They're not without value, but they're not important for determining that someone fucked up.
This is what the poster you're responding to is saying. That the problems are so goddamned egregious that they simply shouldn't be. It's not up to the aforementioned poster to fix the problems, it's up to the companies in question wanting to be better.