All of the help desk techs thought of him as a big thorn in their side, to them it seemed like he called about all the most insignificant issues, and it was almost like he intentionally tried to break things.
This crept over to the developers and management, who would ridicule the guy. But what they didn't know was that he was probably their best tester! All of the other remote offices didn't care that things didn't work right, and assumed the bugs were already known and were never going to be fixed.
I truly felt bad for the guy, he was just trying to get his job done, but ended up being the victim of both bad software, and bad technical support.
At my moms job she was the leiasion for printer problems. You'd think she broke the printer a hundred times, but instead shes the only person that would call support when they happened.
Yet the feedback has been almost non-existent. We just have to assume it all works as intended, but we know that's too good to be true. When we grab people they say "oh yeah, I was going to report a bug but now I can't remember" or we'll see that people just stop using it because of some game-breaking bug, which they never report. Some people even say "don't use it, it's broken" and just assume we magically know about the bugs.
The worst part is many of these projects are explicitly made to help test the API, and help improve it. Yet they don't report anything.
But, and this is the important part: depending on how the company is structured, reporting a bug in a closed source project will result in unplanned work. If the company takes a "everyone is responsible for all bugs, we don't assign blame" then it is likely someone will report it.
If the company, whether explicitly or implicitly, is communicating that if you report the bug, you fix it, then there is a good chance you will not report it, if you own it.
If you own something, you can be fired if you break it. So there is a perverse incentive to not report your own bugs, especially if you inherit a mess.
In my bubble, you have to be very careful about hiring because it can be very difficult to fire anyone at a large company. Or it just ends up being such a long, awkward, multi-stage process, that even objectively terrible engineers will get transferred elsewhere within a large company rather than get fired, because it's that much easier for the manager who wants to get rid of them.
Some of it might be a cultural affinity for giving people second chances, but I think a lot of it is just the hoops you have to jump through to avoid the possibility of a future wrongful termination lawsuit if you fire somebody. But I've heard that it can be very different elsewhere, in different industries or countries. I bet it has a lot to do with the legal system too, like whether or not there's a framework of worker protection laws in place.
It probably wasn't the most popular product to begin with, but I am still amazed that nobody even noticed the drop in sales.
Worse still is putting your manuals behind a login. I know some companies believe they're valuable secrets for some reason, but most of your customers will simply never be able to log in to get them.
In these cases, you will never recoup your NRE.
Oracle has sued competitors for handing out copies of the manual, suggesting requiring a login isn't much of a barrier: https://www.bizjournals.com/sanjose/news/2013/06/18/oracle-w...
Sometimes, you have used your own code way too much to judge effectiveness.
Having a no-agenda meeting with users is also a great idea, but it is important to set scope on feature requests before it snowballs into a request for the moon.
You have to learn to really watch people when they’re using your team’s code. It’s so much clearer than listening to them bitch about the three things that triggered them.