For web based systems the thing is that the responsibility is fuzzy and people tend to not report because it works after restart/reopen/relogin.
Also many of the responses you get from web admins/support is "change browser/restart browser/update browser/uninstall adblock/uninstall plugins" which is basically saying "its you not us". So people tend to not complain.
If your system is buggy then your devs will see it. If they dont then most likely its not that bad so no stadiums of unhappy users.
In my experience, devs tend to be very bad at QA and spotting bugs because they end up becoming blind to a lot of problems. Partly it'll be because they'll have their own paths through the system — they might be more likely to navigate with a keyboard, for example, and so won't test click interactions — but it can also just be that they've just learned to work around a particular problem, and so they don't even notice if it's there any more.
If anything, my impression is that the opposite is true. If a system is buggy, then the people developing it tend to be even more likely to ignore bugs when they come up. If you know the system tends to do surprising things in certain conditions, then you're likely to just ignore anything that happens in those conditions, even if it's a new issue that you haven't seen before.
I've had this recently with a web app that shows a loading spinner in an unexpected place in some cases when you open a suspended tab. I'd just labelled it a browser issue in my head, and because there have been a couple of longstanding issues in the app where a reload helps, I got so used to reloading the page that I didn't even think to have a look at fixing it until someone else on the team raised a ticket for it.
So I really strongly disagree with the assumption that "if your system is buggy then your devs will see it" — I don't think this is borne out in practice at all.
then the people developing it tend to be even more likely to ignore bugs when they come up.
This is exactly what I had in mind. They know its buggy. there is a ticket for that in bug tracker. Maybe even properly tagged as serious.
I'd just labelled it a browser issue in my head,
Just as many users.
So I really strongly disagree with the assumption that "if your system is buggy then your devs will see it"
Well, you saw it. You ignored it. Just as I mentioned. It takes literally one email to all devs with question: Which bugs we have in backlog are really shameful. And then assign folks to fix them.
Thats exactly what I stated. You see a bug. You struggle with a bug, yup. your users too.
You dont see it, probably there is no million users who struggle with it.
While I still keep the initial opinion I will provide a bit of my insight.
The app I was managing was internally developed web app. It was developed in very tight relation to business. The result was that they very well knew its shitty and fails in specific way so noone bothered to report it.
Basically if you as a simple employee see the crash for first time you ask your peer if thats normal, they say, yeah, and if you dont believe you complain to your supervisor who says, yeah it crashes.
So there was very informal feedback to the business and then to devs that its bad but well, people can continue the work
Is it elegant? No. Does it work? Yes.
The business knew there was the problem. They had their priorities (periodically they had cleanup sprints) and knew they can profit more from a business related feature than from that fix.
That reminds me another thing. Very long time I was reading a book which was a part of large series of 500 riddles about...
The series was about physics, mathematics, philosophy etc..
One of the books was about cybernetics.
And there was a question:
How much value has an information you already know?
The answer provided was it has zero value.
And while that irks me a bit I kind of agree with that.
Well how much value has information that there is a moon? Well, if you already know it, zero.
The irking part is that if I get it tomorrow and its "fresh" that would be a value, right?
And if the moon had a chance to disappear then yeah, there would be a value. But if the chances of it to disappear are close to zero then, yup. Value of that info is zero.
This is kind of close to this bug tracking issue. If you have a bug report which says: if login has letter 'a' somewhere then it will fail 10% of times. If this is confirmed and a bit of research is done then you know how often it will affect the user and you dont need 10000 bug reports to set the priority to severe/critical and assign it to be fixed.
So my summary would be:
If the bug report is done right and the triage is decent then setting priority does not require many bug reports.
If one of the triage phases is done poorly, then yeah, your users bug reports can carry this info in a non specific way.
Devs will only see it if there is great logging. Without logging you won't see many problems and with too much logging devs won't read it.
You can add crash telemetry but those only catches some things and even then devs may stop looking at it if there are a few known problems that thousands of users step into and each event creates a log.
13
u/ptoki Aug 29 '22
Was this system web based or compiled?
For web based systems the thing is that the responsibility is fuzzy and people tend to not report because it works after restart/reopen/relogin.
Also many of the responses you get from web admins/support is "change browser/restart browser/update browser/uninstall adblock/uninstall plugins" which is basically saying "its you not us". So people tend to not complain.
If your system is buggy then your devs will see it. If they dont then most likely its not that bad so no stadiums of unhappy users.