[Leherenn]

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").

[Natsu]

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]

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.

[Natsu]

You know what was the saddest thing? After all that effort, I got some blow-back for the fix taking so long.

[ATMLOTTOBEER]

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

[butlike]

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

[hsbauauvhabzb]

Why would they do that when they could waste your time instead?

[jiggawatts]

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."

[b112]

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]

High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.

[Bratmon]

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]

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]

So build barely usable products that force people to pay for support as an upsell.

[dTal]

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.

[eviks]

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]

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.

[tialaramex]

Outsiders can't see the internal ticket, but e.g. 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.

[rkagerer]

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.

[nerdile]

It is different when you have a billion customers, all with different setups. At that scale, you notice real defects through product telemetry, support ticket volume, or trusted channels. You receive a high volume of bug reports that are due to user confusion, misconfiguration, or misbehavior of other software on the device - where solving an issue for one customer doesn't result in improvements for the other billion. Triage, filtering, and winnowing are necessary here.

[rkagerer]

I got a lot of those too, it meant I inevitably did a little bit of free tech support for my customers. In the end I felt it was worth it as they raved about the quality of support and it was a real differentiator - not to mention built a lot of brand loyalty (and internal staff loyalty too once I grew enough to build out a team - they derived real satisfaction from actually solving problems instead of playing ping-pong).

I agree regarding the need to triage at scale, unfortunately most large companies I've encountered fail to do this well and seem ill-equipped to accept high quality bug reports of edge case defects generated by expert users (save for the odd exception that arrives by social media from someone who happens to have enough followers to get their attention outside the regular support pipeline).

In my experience this doesn't usually boil down to a systems issue (the ticketing systems etc. exist that should theoretically allow for eventual escalation to the right engineer/developer) but a corporate culture thing (the company just doesn't prioritize customer feedback especially at the level where staff who actually deal with customers interface with the teams that write/maintain the software). Often it's genuinely valued at the C-level (the Bezos story of calling Amazon"s tech support line during an exec meeting is a fun example) but diluted somewhere between them and the rank-and-file.

(Ps. I'm not arguing with you and appreciate you took the time to craft a thoughtful reply)

[account42]

It should be the other way around - at billion customer scale you should be responsible for how your product interacts with other software whose developers have less resources than you.

[eob]

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]

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]

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]

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.

[hsbauauvhabzb]

You’ve just described AGILE development, a way for product owners to backlog code rot while empowering developers to feel like they have a say in things.