6 ms·

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),

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 6mo 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 6mo ago
  High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.
  - Bratmon 6mo 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.
    - eviks 6mo 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
    - atherton94027 6mo 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 6mo ago
        So build barely usable products that force people to pay for support as an upsell.
        dTal 6mo 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 6mo ago
        ‘Oh you want to access help documents indexed by google? Please show us your enterprise licence to continue.’
- glitchc 6mo 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 6mo 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.
- Neywiny 6mo 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 6mo 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 6mo ago
    You know what was the saddest thing? After all that effort, I got some blow-back for the fix taking so long.
  - ATMLOTTOBEER 6mo ago
    The actual soln is to use oss stuff and aggressively send claude code into the weeds whenever you find a big, then upstream the fixes. I switched from IntelliJ to emacs for this reason and it’s been great
- nradov 6mo ago
  [flagged]
jiggawatts 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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.

b112 6mo 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 6mo ago
High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.
- Bratmon 6mo 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.
  - eviks 6mo 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
  - atherton94027 6mo 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 6mo ago
      So build barely usable products that force people to pay for support as an upsell.
      - dTal 6mo 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 6mo ago
        ‘Oh you want to access help documents indexed by google? Please show us your enterprise licence to continue.’
glitchc 6mo 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 6mo 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.

Neywiny 6mo 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 6mo 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 6mo ago
  You know what was the saddest thing? After all that effort, I got some blow-back for the fix taking so long.
- ATMLOTTOBEER 6mo ago
  The actual soln is to use oss stuff and aggressively send claude code into the weeds whenever you find a big, then upstream the fixes. I switched from IntelliJ to emacs for this reason and it’s been great
nradov 6mo ago
[flagged]

jiggawatts 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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.