Hacker News Reader

Comment by 2rsf | Hacker News Reader

You are writing this based on gut feeling, big companies simply can't go over every bug report- it's not scalable.

I used to work on a product at a big company, we took users input very seriously, not only from bug reports but also by analyzing telemetrics data and simple users "star" feedback.

At the end of the day it's simply impossible to both fix everything and still go forward when the product is big and complex. To this day the product has terrible reputation as buggy and unfriendly.

Even the simple task of finding what the problem is, fixing it and then closing related problem reports is very complex since many bugs manifest themselves in different ways.

View on HN

> You are writing this based on gut feeling, big companies simply can't go over every bug report- it's not scalable.

I often hear this repeated, and I keep wondering: why? Why is it not scalable?

Apple had 265 billion dollars of revenue in 2018. I'm spending 10% of my budget on QA. So, in the case of Apple, if you had a 26 billion dollar budget (give or take a few billion) for your QA department, why couldn't you go over every bug report?

It's definitely possible, it's just that companies are making a different tradeoff, assuming that bugs will not influence buying decisions that much. And to a certain extent they are right.

Because software is just not something you can just throw more money and people at and expect it to get better. In fact, that is the surest way to make a piece of software worse.

Software, despite all the attempts to come up with ways to commoditize its production, does not scale.

But we are talking about reading bug reports, not writing software. Also, I would argue that finding and fixing bugs actually does scale, as opposed to designing and writing new systems.

You need the small subset of people who actually understand how the software works to fix the bugs, lest you just end up playing whack-a-mole and introducing new bugs.

Ideally, it wouldn't be like this, but we don't live in an ideal world, and there's always some unintended consquence when you start pulling the string on anything nontrivial. And there's never sufficient automated testing, especially for the things that haven't been a problem yet.

Fixing the bugs is one thing, but identifying that user reported bugs are in fact bugs is an entirely separate issue. The latter takes a ton of time, requires no developers, and is what everyone above you in this thread is talking about.

The GP comment that spawned this thread said this:

> If Apple also spent 10% of its revenue on processing bug reports and fixing bugs,

"fixing bugs."

So, fixing bugs is 100% part of the discussion here.

But, let's ignore that for a second.

Let's say Apple triages all its bugs, but then doesn't fix them.

How is that an improvement? How is triaging the bugs but not fixing them at all an improvement?

How do you recognize 100,000 reports of the same bug but different manifestation ? What if it's an architectural issue (and many bugs are)? What if you are already working on a total re-write that's going to be released in 2 releases ? What do you do with bugs found internally ?

Also remember that many bugs requires much more then changing a couple of lines of code, they require cross module changes and re-testing which can lead to more bugs.

Does the Chrome team go over every bug report? It seems like it to me, though I've only filed a few.

They also ignore bugs for a decade or more.

> To this day the product has terrible reputation as buggy and unfriendly.

In what way is that an argument against paying attention to bug reports? Are you saying that the continuing existence of this product means it does not matter? Arguably that strategy will work, up to the point when something better comes along, and by then you will be too deep in bugs to pivot.

We did fix customers bugs, I don't know that exact investment made but it was not trivial at all- and still bugs were found and not all of them fixed.

This specific product grew to be an abomination which in part is responsible for the many complaints it gets.

Automotive companies do, though.

maybe in the safety critical parts, but do they fix entertainment system bugs ?

That's quickly becoming the main point of differentiation in most reviews since cars in a certain class have become more or less the same performance wise.

Speaking from the perspective of just wrapping up the car buying process. All of the reviews had just as many, if not more words devoted to the infotainment experience as to the driving experience.

Here I am thinking Bluetooth is peak feature so I can play my music while carving canyons and reviewers are taking off points because the touch screen isn't colorful enough or something.

But as I've been saying for a few years now, most people don't want to drive. They'd much rather be driven so they can mess with their phones.

I want to be driven because it's safer and usually more relaxing, even though I like to drive.

And I want my Bluetooth connection to work flawlessly but it never does.

Or the Bluetooth connection works, but does random things you can't change. The last rental car I had, upon connection, forced Spotify to re-open and start playing the last playlist. Even if Spotify was closed.

Some entertaining solutions I found online include a playlist that includes only silent tracks and switching to that playlist before you turn off the car, or canceling Spotify Premium so you can no longer download/cache songs, giving you enough time to mute before Spotify's cloud can stream the song to the car.

I want to drive. Just not to work (or the shops, or anywhere else on a daily basis).

Reply on news.ycombinator.com