6 ms·

Author must not have worked in enterprise software before. That's a classic trick where the developer will push back on the bug author and say "I can't reprodu

Author must not have worked in enterprise software before. That's a classic trick where the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything. And if it doesn't get confirmed then they can close it as User Error or Not Reproducible. Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.

Leherenn 7mo ago
From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").
- b112 7mo ago
  It'd kind of sad, how the market went. I suppose there are pluses too. But back in the 80s and 90s, margins were significantly higher. If you look at hardware, I recall selling hardware with 30% margin, if not more... even 80% on some items. Yet what came with that was support, support, support. And when you sell 5 computers a month, instead of 500, well.. you need that margin to even have a store. Which you need, because no wide-scale internet. On the software side, it was sort of the same. I remember paying $80 for some pieces of software, which would be like $200 today. You'd pay $1 on an app store for such software, but I'd also call the author if there was a bug. He'd send an update in the mail. I guess my point is, in those days, it was fun to fix issues. The focus was more specific, there was time to ply the trade, to enjoy it, to have performant, elegant fixes. Now, it's all "my boss is hassling me and another bug will somehow mean I have to work harder", which is .. well, sad.
  - nradov 7mo ago
    High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.
    - Bratmon 7mo ago
      Exactly! The "pay a lot of money but get really good support" tier still exists just about everywhere. You just didn't do the first part.
      - atherton94027 7mo ago
        It really depends, support is usually the first thing companies adjust when they want to improve their margins. Even when you're paying millions to AWS you have to get through their first line of support and they will ask silly questions until you can convince them to escalate.
        hsbauauvhabzb 7mo ago
        So build barely usable products that force people to pay for support as an upsell.
        dTal 7mo ago
        Aka the Red Hat business model. It's all you have when access to the product itself is free. Gotta keep yourself in the loop somehow.
        hsbauauvhabzb 7mo ago
        ‘Oh you want to access help documents indexed by google? Please show us your enterprise licence to continue.’
      - eviks 7mo ago
        Not really, you get "really dedicated support" at most, but not a "really good" one, otherwise all those decades-old bugs common in many software producs would've been fixed since they affect people at all tiers
  - glitchc 7mo ago
    Back then, computers didn't had competition from the analog world, so vendors had to provide excellent service such that users would be convinced into switching over to the digital way if doing things. Now comouters have a monopoly on how we work and live, so vendors care as little as possible.
- Natsu 7mo ago
  I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eitehr. Turns out there was a known bug in Microsoft schannel that had yet to be patched and they'd wasted weeks of our effort by not searching their own bug tracker properly.
  - nradov 7mo ago
    [flagged]
  - hsbauauvhabzb 7mo ago
    Why would they do that when they could waste your time instead?
  - Neywiny 7mo ago
    I hate that so much. It's everywhere. An example is a bug with discord. They wanted me to restart my phone, reinstall the app, what are my versions, what phone am I on, what settings, etc. After all of that they go "oh that's a known issue." Whyyyyyyyyyyy. I get that multiple things can have the same symptom, but maybe start with that. Not like I signed any NDA so they aren't hiding it's an issue from the public.
    - butlike 7mo ago
      puts on paranoid hat It could be to demoralize you so you subconsciously decide to not file a bug next time, knowing all the rigamarole you'd have to go through. takes off paranoid hat
    - Natsu 7mo ago
      You know what was the saddest thing? After all that effort, I got some blow-back for the fix taking so long.
    - ATMLOTTOBEER 7mo ago
- jiggawatts 7mo ago
  My favourite variant of this merrygoround is when they ask you to demonstrate the issue live in a Teams session, you do so, and there's this moment of silence followed by an "Oh... I see". Then you assume, naively, that this means that they've recognised that there really is a product problem and will go off and fix it. However, then in turn the support tech needs to reproduce the the issue to the development team. They invariably fail to do so for any number of reasons, such as: This only happens in my region, not others. Or the support tech's lab environment doesn't actually allow them to spin up the high-spec thing that's broken. Or whatever. Then the ticket gets rejected with "can't reproduce" after you've reproduced the issue, with a recorded video and everything as evidence. If you then navigate that gauntlet, the ticket is most typically rejected with "It is broken like that by design, closed."
- rkagerer 7mo ago
  That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability. They would not remain employed in my company. When I developed software I would jump right on top of any bug reports immediately, and work until they were fixed. I was grateful to my customers for bringing them to my attention.
  - eob 7mo ago
    My guess it's just the emergent behavior that results when a company doesn't provide developers time to fix bugs. If their week is already booked full just trying to keep up with the roadmap deadlines, a bug ticket feels like being tossed a 25lb weight when you're drowning. You could say: "but have pride in your work!" But if your company only values shipping, not fixing, that attitude doesn't make it through the first performance review.
    - nradov 7mo ago
      What I've found to be most effective for program management is to set aside a maintenance team separate from the feature teams. The roadmap is then planned without counting anything for the maintenance team and they deal with bug tickets as they come in. Rotate the assignment periodically so that every developer has to occasionally spend a few months on the maintenance team.
      - daheza 7mo ago
        Doesn’t this lead to problems like the feature team pushing buggy code and having no accountability or responsibility to deal with it? My preference is to treat the defects like feature work, size and plan. Yes you might not get all the feature work done but the team is accountable for everything they make
        nradov 7mo ago
        There's a lot more to effective program quality management than I can explain in a comment here. Forcing all developers to rotate through the maintenance team is one incentive not to ship crap because they might end up having to deal with it anyway. But more importantly you have to shift left the quality assurance and control activities to minimize the risk of defect leakage in the first place. And set up a closed-loop system where any leaked defect triggers a rigorous root-cause analysis that results in further process improvement.
- tialaramex 7mo ago
  Outsiders can't see the internal ticket, but e.g. https://github.com/microsoft/STL/issues/4448 https://github.com/microsoft/STL/issues/4448 This is simply a bug, it's an implementation mistake, it's even possible to imagine from what we do know about the implementation inside Windows to imagine how you'd likely write that bug, simply you're writing the "lock stealing" code and you realise you need some context -- are we stealing the write lock or the read lock? You realise that context won't fit in your tiny flag budget (flag bits are hidden in the bottom of a pointer) and you forget that you actually know this context at the exact moment you need it - you were asked for either a write lock or a read lock, that's what you're stealing. So, you write code which does what it can without the context, always steal the write lock. Oops. Bug. And yet several people insist that this wasn't a bug it's actually the proper way for this to function. Not only in this github ticket, and in the Microsoft internal bug, but I saw several third parties defend the bug as obviously the correct way for this to work. Fortunately it seems STL understood that and the internal ticket was eventually fixed and (presumably) in Windows 11 today this bug is fixed.
masklinn 7mo ago
> Author must not have worked in enterprise software before. Or with open source projects. Fucking stalebot.
- IshKebab 7mo ago
  Fuck stalebot.
  - monster_truck 7mo ago
    All my homies hate stalebot
  - tkfoss 7mo ago
    What about OSS weekend ?
- bmitc 7mo ago
  Take a look at Anthropic's repo. They auto-close issues after just a few weeks. I don't think I've seen an issue of theirs that wasn't auto-closed.
  - tchalla 7mo ago
    Wait, isn’t software engineering a solved problem?
    - vpShane 7mo ago
      Yes
    - what 7mo ago
      Yes, that’s why they have such great up time. They don’t go down multiple times per day.
  - no-name-here 7mo ago
    I just randomly plugged in numbers to look up random Claude issues on github, and out of the 20 I checked, only one was closed as fixed. :-(
lucasay 7mo ago
[dead]
bloodyplonker22 7mo ago
If you are a veteran of software in a big company, we all know there will be weekly or bi-weekly meetings that some PM will set up. All the PM will do is go over the JIRA tickets and be like "is this still happening". Default answer is "no", as in "I didn't even try to reproduce it, do you think I have time to even do it?". Default answer by spineless QA person is also "didn't try it again yet". Then, the PM closes the ticket. It is much easier for QA person to say "Yes I verified it" if you are remote and developer cannot see the lies on your bad poker face.
- thrtythreeforty 7mo ago
  Ooh this gives me an interesting passive-aggressive idea to counter pointless "is this still relevant" questions. "No, I haven't hit this in the last 2 days." "No, I haven't hit this since I gave up trying to do it with your tool." And so forth. The less passive-aggressive version is to use this obviously-unhelpful answer of the obviously-unhelpful question, to actually have a conversation to get the PM to recognize that the default state of a ticket is in fact "no change." Ultimately that may turn into a stale bot if the PM realizes the policy they actually want is some sort of timeout, but at least it's not a time consuming meeting! (Note, a cathartic thought experiment, but not really good manners to actually do!)
- gib444 7mo ago
  Absolutely spot on LOL
beembeem 7mo ago
Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. I've seen this in my work and it makes me sad for the user, but it often does take a bit of effort to spear these bug reports through.
- falcor84 7mo ago
  It's a false dichotomy - something being "a simple cost/benefit analysis" doesn't remove the ethical dimension, and can absolutely be nefarious. A movie villain saying "it was just business" doesn't make their actions less villainous.
- conductr 7mo ago
  I’d argue that there should be no higher business priority than shipping a product you already sold. If you sold a product and your customer spends their time documenting exactly why and how you sold them something that’s broken, you should make that a high priority. As a natural progression, you’ll start shipping less buggy / better tested products and that’s how you unlock yourself from the obligation you made to your existing customers to do other work. Not directed at you of course, just the proverbial “you” from the frustration of a purchaser of software.
  - FridgeSeal 7mo ago
    Careful saying that too loudly, the “ship new features at all costs” gang will come for your head. They don’t approve of things like “quality software” and “making stuff that works past the demo and cursory inspection” or “actual user utility”.
- nradov 7mo ago
  I totally understand that from the perspective of individual employees: they have little incentive to do more than the bare minimum to close tickets. But this behavior is typically a symptom of broken corporate culture and failure to align internal metrics. For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it, and badmouth you to other customers. Doing deep investigations of even minor bug reports also tends to expose other, more serious latent bugs. And root cause analysis allows you to create closed-loop solutions to prevent similar future bugs. Large monopolistic tech companies like Apple and Microsoft can afford to ignore this stuff for years because there are few realistic alternatives. But longer term eventually a disruptive competitor comes along who takes product quality and customer service more seriously.
bmitc 7mo ago
I also hate this pressure of it being on the user to come up with a minimal reproducing example. That means that any bug of any moderate complexity will never get fixed because you can't always reduce them to a few steps and they may be statistical. A bug is a bug, no matter the developers' opinion or the complexity of the bug.
- account42 7mo ago
  However there are "bugs" that actually do turn out to be just cosmic rays flipping bits or plain user error. If you as the reporter don't provide enough information for the developer to be sure they are not going on a wild goose chase then it's fair for the developer to not invest too much time.
  - bmitc 7mo ago
    Sure. But I'm biased because I was a "customer" of a former (large) company's products while also working at that company. So the bugs I would file were the type that a customer would file, but since I was inside, I saw how they were handled. The tactics that my fellow R&D developers would do to claim something wasn't a bug or reproducible were nearly endless.
lapcat 7mo ago
> Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it. I'm not going to lie. That's not who I am. If Apple really wants to close a bug report when the bug isn't fixed, that's on their conscience, if they have one.
- loloquwowndueo 7mo ago
  Companies have no consciences.
  - parasubvert 7mo ago
    Companies are made of humans who do.
    - ikiris 7mo ago
      I think you and I have had vastly different experiences of the normal level of conscience in companies.
      - parasubvert 7mo ago
        Possibly, though generally speaking you don't have to look hard to find people with conscience and ethics in companies, they're abundant.
    - g947o 7mo ago
      I guess that explains why social media companies try to maximize engagement even though it is almost bad for your mental health in every way. Or does it?
    - deleted 7mo ago
      [deleted]
    - loloquwowndueo 7mo ago
      So was the Nazi regime, and yet…
98codes 7mo ago
I got reeeeally good at producing repro gifs that I could plug straight inline into email replies to "can't repro"; it's forever clear that most developers either don't know how to test the product they are building, or simply can't be bothered to try.
crest 7mo ago
I've worked with enterprise software. The result its that people will eventually just wait a few hours/days and lie if they even care enough to do that. The perverse incentives destroy what utility a bug tracker could bring. Int theory transparency could help by changing the incentives if third parties analyze the metrics and call out bullshit to an audicence that matters.
ryukoposting 7mo ago
Hi, bigcorp employee getting showered with tickets here. I don't have enough time in the day to deal with the tickets where the reporter actually tries, let alone the tickets where they don't. If I tell you to update your shit, it's because it's wildly out of date, to the point that your configuration is impossible for me to reproduce without fucking up my setup to the point that I can't repro 8 other tickets.
- NetMageSCW 7mo ago
  Please tell us where you work so we can avoid all of your company’s software. Unless it’s Microsoft, because we’ve already seen the results of that attitude there.
  - ryukoposting 7mo ago
    I don't see how it's an unreasonable request. If you demand that I work with some ancient version, I then have to install and uninstall said program every time I work on your ticket specifically. You will be prioritized last, because my effectiveness is measured by how many tickets I close.
    - tefkah 7mo ago
      just bc everyone is calling you insane: you are being extremely reasonable.
      - cxr 7mo ago
        Flagging isn't supposed to be used as a super downvote. There's a term for the bizarre behavior and thought processes (read: justification) by the person you're responding to. <https://en.wikipedia.org/wiki/Occupational_psychosis https://en.wikipedia.org/wiki/Occupational_psychosis> > you are being extremely reasonable They're not. If there's nothing wrong with it, one could ask whether the person here would be okay sitting in a room with their supervisor, the head of the company, and 10 customers, say the same things they're saying here, and get a consensus that this is how this should all work out.
tonetheman 7mo ago
[dead]
whatever1 7mo ago
I mean if the customer stops complaining, either the bug was fixed, or the bug was not too important to begin with, or they are not a customer anymore and nobody else cares about that niche bug. In all of the above closing the ticket sounds reasonable. What is not reasonable is that they close issues with thousands of “I have this issue too” with active complains and full repros
magicalhippo 7mo ago
> the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything. We do this. Because frankly, very often the bug has been reported by others and has been fixed, we just can't connect the dots in our ticketing system. That's of course less than ideal, but given that a lot of tickets we get are often very poorly described it's hard. It's one aspect I have genuine hope AI can help us with.
farhanhubble 7mo ago
I wish someone had told me how common this was back when I worked myself to death fixing every UI abnormality that no one except some misincentivized testers used to report at my first job. At the time I thought it was dishonest to say something was irreproducible and it'd be beneath me to patch an issue knowing it'll sprout ten others. I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.
opan 7mo ago
I've been on both sides of this. Absolutely sucks as a user falling prey to stalebot or some poor sap pretending to be stalebot, but when I was working in enterprise tech support it was a huge relief to close a case and get it off my plate, for any reason. We had to take 2 new cases per day minimum, update each case (I often had 20+) every few days minimum. Only a small minority were a quick and easy solution (like security vulns with a fix ready we could send the customer were the easiest). We were stuck with our cases also, you couldn't give them to someone else unless you were out sick pretty much, and you'd get them back when you returned unless by some miracle the other guy fixed their problem. An inactivity close on a stalled case was comforting, I was finally free. I think they started cracking down after a bit and said you had to check in with them 3 times x days apart first instead of just immediately closing after no word for 2 weeks, and then they wanted you to call them first. Absolute nightmare. I think as long as the issue isn't stuck with any one person then it's easier to leave open until it's actually fixed, like the 20+ year old Mozilla bug reports. Big corpo bureaucratic nonsense just ruins everything.
Nekorosu 7mo ago
Is your argument "it's bad everywhere, so it's ok"? As a software developer I do understand how enterprises operate, as a customer and a user I'd put Apple under higher scrutiny and would expect better.

Leherenn 7mo ago

From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").

b112 7mo ago
It'd kind of sad, how the market went. I suppose there are pluses too. But back in the 80s and 90s, margins were significantly higher. If you look at hardware, I recall selling hardware with 30% margin, if not more... even 80% on some items. Yet what came with that was support, support, support. And when you sell 5 computers a month, instead of 500, well.. you need that margin to even have a store. Which you need, because no wide-scale internet. On the software side, it was sort of the same. I remember paying $80 for some pieces of software, which would be like $200 today. You'd pay $1 on an app store for such software, but I'd also call the author if there was a bug. He'd send an update in the mail. I guess my point is, in those days, it was fun to fix issues. The focus was more specific, there was time to ply the trade, to enjoy it, to have performant, elegant fixes. Now, it's all "my boss is hassling me and another bug will somehow mean I have to work harder", which is .. well, sad.
- nradov 7mo ago
  High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.
  - Bratmon 7mo ago
    Exactly! The "pay a lot of money but get really good support" tier still exists just about everywhere. You just didn't do the first part.
    - atherton94027 7mo ago
      It really depends, support is usually the first thing companies adjust when they want to improve their margins. Even when you're paying millions to AWS you have to get through their first line of support and they will ask silly questions until you can convince them to escalate.
      - hsbauauvhabzb 7mo ago
        So build barely usable products that force people to pay for support as an upsell.
        dTal 7mo ago
        Aka the Red Hat business model. It's all you have when access to the product itself is free. Gotta keep yourself in the loop somehow.
        hsbauauvhabzb 7mo ago
        ‘Oh you want to access help documents indexed by google? Please show us your enterprise licence to continue.’
    - eviks 7mo ago
      Not really, you get "really dedicated support" at most, but not a "really good" one, otherwise all those decades-old bugs common in many software producs would've been fixed since they affect people at all tiers
- glitchc 7mo ago
  Back then, computers didn't had competition from the analog world, so vendors had to provide excellent service such that users would be convinced into switching over to the digital way if doing things. Now comouters have a monopoly on how we work and live, so vendors care as little as possible.
Natsu 7mo ago
I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eitehr. Turns out there was a known bug in Microsoft schannel that had yet to be patched and they'd wasted weeks of our effort by not searching their own bug tracker properly.
- nradov 7mo ago
  [flagged]
- hsbauauvhabzb 7mo ago
  Why would they do that when they could waste your time instead?
- Neywiny 7mo ago
  I hate that so much. It's everywhere. An example is a bug with discord. They wanted me to restart my phone, reinstall the app, what are my versions, what phone am I on, what settings, etc. After all of that they go "oh that's a known issue." Whyyyyyyyyyyy. I get that multiple things can have the same symptom, but maybe start with that. Not like I signed any NDA so they aren't hiding it's an issue from the public.
  - butlike 7mo ago
    puts on paranoid hat It could be to demoralize you so you subconsciously decide to not file a bug next time, knowing all the rigamarole you'd have to go through. takes off paranoid hat
  - Natsu 7mo ago
    You know what was the saddest thing? After all that effort, I got some blow-back for the fix taking so long.
  - ATMLOTTOBEER 7mo ago
jiggawatts 7mo ago
My favourite variant of this merrygoround is when they ask you to demonstrate the issue live in a Teams session, you do so, and there's this moment of silence followed by an "Oh... I see". Then you assume, naively, that this means that they've recognised that there really is a product problem and will go off and fix it. However, then in turn the support tech needs to reproduce the the issue to the development team. They invariably fail to do so for any number of reasons, such as: This only happens in my region, not others. Or the support tech's lab environment doesn't actually allow them to spin up the high-spec thing that's broken. Or whatever. Then the ticket gets rejected with "can't reproduce" after you've reproduced the issue, with a recorded video and everything as evidence. If you then navigate that gauntlet, the ticket is most typically rejected with "It is broken like that by design, closed."
rkagerer 7mo ago
That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability. They would not remain employed in my company. When I developed software I would jump right on top of any bug reports immediately, and work until they were fixed. I was grateful to my customers for bringing them to my attention.
- eob 7mo ago
  My guess it's just the emergent behavior that results when a company doesn't provide developers time to fix bugs. If their week is already booked full just trying to keep up with the roadmap deadlines, a bug ticket feels like being tossed a 25lb weight when you're drowning. You could say: "but have pride in your work!" But if your company only values shipping, not fixing, that attitude doesn't make it through the first performance review.
  - nradov 7mo ago
    What I've found to be most effective for program management is to set aside a maintenance team separate from the feature teams. The roadmap is then planned without counting anything for the maintenance team and they deal with bug tickets as they come in. Rotate the assignment periodically so that every developer has to occasionally spend a few months on the maintenance team.
    - daheza 7mo ago
      Doesn’t this lead to problems like the feature team pushing buggy code and having no accountability or responsibility to deal with it? My preference is to treat the defects like feature work, size and plan. Yes you might not get all the feature work done but the team is accountable for everything they make
      - nradov 7mo ago
        There's a lot more to effective program quality management than I can explain in a comment here. Forcing all developers to rotate through the maintenance team is one incentive not to ship crap because they might end up having to deal with it anyway. But more importantly you have to shift left the quality assurance and control activities to minimize the risk of defect leakage in the first place. And set up a closed-loop system where any leaked defect triggers a rigorous root-cause analysis that results in further process improvement.
tialaramex 7mo ago
Outsiders can't see the internal ticket, but e.g. https://github.com/microsoft/STL/issues/4448 https://github.com/microsoft/STL/issues/4448 This is simply a bug, it's an implementation mistake, it's even possible to imagine from what we do know about the implementation inside Windows to imagine how you'd likely write that bug, simply you're writing the "lock stealing" code and you realise you need some context -- are we stealing the write lock or the read lock? You realise that context won't fit in your tiny flag budget (flag bits are hidden in the bottom of a pointer) and you forget that you actually know this context at the exact moment you need it - you were asked for either a write lock or a read lock, that's what you're stealing. So, you write code which does what it can without the context, always steal the write lock. Oops. Bug. And yet several people insist that this wasn't a bug it's actually the proper way for this to function. Not only in this github ticket, and in the Microsoft internal bug, but I saw several third parties defend the bug as obviously the correct way for this to work. Fortunately it seems STL understood that and the internal ticket was eventually fixed and (presumably) in Windows 11 today this bug is fixed.

masklinn 7mo ago

> Author must not have worked in enterprise software before. Or with open source projects. Fucking stalebot.

IshKebab 7mo ago
Fuck stalebot.
- monster_truck 7mo ago
  All my homies hate stalebot
- tkfoss 7mo ago
  What about OSS weekend ?
bmitc 7mo ago
Take a look at Anthropic's repo. They auto-close issues after just a few weeks. I don't think I've seen an issue of theirs that wasn't auto-closed.
- tchalla 7mo ago
  Wait, isn’t software engineering a solved problem?
  - vpShane 7mo ago
    Yes
  - what 7mo ago
    Yes, that’s why they have such great up time. They don’t go down multiple times per day.
- no-name-here 7mo ago
  I just randomly plugged in numbers to look up random Claude issues on github, and out of the 20 I checked, only one was closed as fixed. :-(

lucasay 7mo ago

[dead]

bloodyplonker22 7mo ago

If you are a veteran of software in a big company, we all know there will be weekly or bi-weekly meetings that some PM will set up. All the PM will do is go over the JIRA tickets and be like "is this still happening". Default answer is "no", as in "I didn't even try to reproduce it, do you think I have time to even do it?". Default answer by spineless QA person is also "didn't try it again yet". Then, the PM closes the ticket. It is much easier for QA person to say "Yes I verified it" if you are remote and developer cannot see the lies on your bad poker face.

thrtythreeforty 7mo ago
Ooh this gives me an interesting passive-aggressive idea to counter pointless "is this still relevant" questions. "No, I haven't hit this in the last 2 days." "No, I haven't hit this since I gave up trying to do it with your tool." And so forth. The less passive-aggressive version is to use this obviously-unhelpful answer of the obviously-unhelpful question, to actually have a conversation to get the PM to recognize that the default state of a ticket is in fact "no change." Ultimately that may turn into a stale bot if the PM realizes the policy they actually want is some sort of timeout, but at least it's not a time consuming meeting! (Note, a cathartic thought experiment, but not really good manners to actually do!)
gib444 7mo ago
Absolutely spot on LOL

beembeem 7mo ago

Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. I've seen this in my work and it makes me sad for the user, but it often does take a bit of effort to spear these bug reports through.

falcor84 7mo ago
It's a false dichotomy - something being "a simple cost/benefit analysis" doesn't remove the ethical dimension, and can absolutely be nefarious. A movie villain saying "it was just business" doesn't make their actions less villainous.
conductr 7mo ago
I’d argue that there should be no higher business priority than shipping a product you already sold. If you sold a product and your customer spends their time documenting exactly why and how you sold them something that’s broken, you should make that a high priority. As a natural progression, you’ll start shipping less buggy / better tested products and that’s how you unlock yourself from the obligation you made to your existing customers to do other work. Not directed at you of course, just the proverbial “you” from the frustration of a purchaser of software.
- FridgeSeal 7mo ago
  Careful saying that too loudly, the “ship new features at all costs” gang will come for your head. They don’t approve of things like “quality software” and “making stuff that works past the demo and cursory inspection” or “actual user utility”.
nradov 7mo ago
I totally understand that from the perspective of individual employees: they have little incentive to do more than the bare minimum to close tickets. But this behavior is typically a symptom of broken corporate culture and failure to align internal metrics. For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it, and badmouth you to other customers. Doing deep investigations of even minor bug reports also tends to expose other, more serious latent bugs. And root cause analysis allows you to create closed-loop solutions to prevent similar future bugs. Large monopolistic tech companies like Apple and Microsoft can afford to ignore this stuff for years because there are few realistic alternatives. But longer term eventually a disruptive competitor comes along who takes product quality and customer service more seriously.

bmitc 7mo ago

I also hate this pressure of it being on the user to come up with a minimal reproducing example. That means that any bug of any moderate complexity will never get fixed because you can't always reduce them to a few steps and they may be statistical. A bug is a bug, no matter the developers' opinion or the complexity of the bug.

account42 7mo ago
However there are "bugs" that actually do turn out to be just cosmic rays flipping bits or plain user error. If you as the reporter don't provide enough information for the developer to be sure they are not going on a wild goose chase then it's fair for the developer to not invest too much time.
- bmitc 7mo ago
  Sure. But I'm biased because I was a "customer" of a former (large) company's products while also working at that company. So the bugs I would file were the type that a customer would file, but since I was inside, I saw how they were handled. The tactics that my fellow R&D developers would do to claim something wasn't a bug or reproducible were nearly endless.

lapcat 7mo ago

> Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it. I'm not going to lie. That's not who I am. If Apple really wants to close a bug report when the bug isn't fixed, that's on their conscience, if they have one.

loloquwowndueo 7mo ago
Companies have no consciences.
- parasubvert 7mo ago
  Companies are made of humans who do.
  - ikiris 7mo ago
    I think you and I have had vastly different experiences of the normal level of conscience in companies.
    - parasubvert 7mo ago
      Possibly, though generally speaking you don't have to look hard to find people with conscience and ethics in companies, they're abundant.
  - g947o 7mo ago
    I guess that explains why social media companies try to maximize engagement even though it is almost bad for your mental health in every way. Or does it?
  - deleted 7mo ago
    [deleted]
  - loloquwowndueo 7mo ago
    So was the Nazi regime, and yet…

98codes 7mo ago

I got reeeeally good at producing repro gifs that I could plug straight inline into email replies to "can't repro"; it's forever clear that most developers either don't know how to test the product they are building, or simply can't be bothered to try.

crest 7mo ago

I've worked with enterprise software. The result its that people will eventually just wait a few hours/days and lie if they even care enough to do that. The perverse incentives destroy what utility a bug tracker could bring. Int theory transparency could help by changing the incentives if third parties analyze the metrics and call out bullshit to an audicence that matters.

ryukoposting 7mo ago

Hi, bigcorp employee getting showered with tickets here. I don't have enough time in the day to deal with the tickets where the reporter actually tries, let alone the tickets where they don't. If I tell you to update your shit, it's because it's wildly out of date, to the point that your configuration is impossible for me to reproduce without fucking up my setup to the point that I can't repro 8 other tickets.

NetMageSCW 7mo ago
Please tell us where you work so we can avoid all of your company’s software. Unless it’s Microsoft, because we’ve already seen the results of that attitude there.
- ryukoposting 7mo ago
  I don't see how it's an unreasonable request. If you demand that I work with some ancient version, I then have to install and uninstall said program every time I work on your ticket specifically. You will be prioritized last, because my effectiveness is measured by how many tickets I close.
  - tefkah 7mo ago
    just bc everyone is calling you insane: you are being extremely reasonable.
    - cxr 7mo ago
      Flagging isn't supposed to be used as a super downvote. There's a term for the bizarre behavior and thought processes (read: justification) by the person you're responding to. <https://en.wikipedia.org/wiki/Occupational_psychosis https://en.wikipedia.org/wiki/Occupational_psychosis> > you are being extremely reasonable They're not. If there's nothing wrong with it, one could ask whether the person here would be okay sitting in a room with their supervisor, the head of the company, and 10 customers, say the same things they're saying here, and get a consensus that this is how this should all work out.

tonetheman 7mo ago

[dead]

whatever1 7mo ago

I mean if the customer stops complaining, either the bug was fixed, or the bug was not too important to begin with, or they are not a customer anymore and nobody else cares about that niche bug. In all of the above closing the ticket sounds reasonable. What is not reasonable is that they close issues with thousands of “I have this issue too” with active complains and full repros

magicalhippo 7mo ago

> the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything. We do this. Because frankly, very often the bug has been reported by others and has been fixed, we just can't connect the dots in our ticketing system. That's of course less than ideal, but given that a lot of tickets we get are often very poorly described it's hard. It's one aspect I have genuine hope AI can help us with.

farhanhubble 7mo ago

I wish someone had told me how common this was back when I worked myself to death fixing every UI abnormality that no one except some misincentivized testers used to report at my first job. At the time I thought it was dishonest to say something was irreproducible and it'd be beneath me to patch an issue knowing it'll sprout ten others. I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.

opan 7mo ago

I've been on both sides of this. Absolutely sucks as a user falling prey to stalebot or some poor sap pretending to be stalebot, but when I was working in enterprise tech support it was a huge relief to close a case and get it off my plate, for any reason. We had to take 2 new cases per day minimum, update each case (I often had 20+) every few days minimum. Only a small minority were a quick and easy solution (like security vulns with a fix ready we could send the customer were the easiest). We were stuck with our cases also, you couldn't give them to someone else unless you were out sick pretty much, and you'd get them back when you returned unless by some miracle the other guy fixed their problem. An inactivity close on a stalled case was comforting, I was finally free. I think they started cracking down after a bit and said you had to check in with them 3 times x days apart first instead of just immediately closing after no word for 2 weeks, and then they wanted you to call them first. Absolute nightmare. I think as long as the issue isn't stuck with any one person then it's easier to leave open until it's actually fixed, like the 20+ year old Mozilla bug reports. Big corpo bureaucratic nonsense just ruins everything.

Nekorosu 7mo ago

Is your argument "it's bad everywhere, so it's ok"? As a software developer I do understand how enterprises operate, as a customer and a user I'd put Apple under higher scrutiny and would expect better.