Sidebar WTF
-
Bug Report: Half-Life 2 Lost Coast · Issue #618 · ValveSoftware/Source-1-Games
http://www.youtube.com/watch?v=damvrCt2nBo
-
@Ben L. said:
https://github.com/ValveSoftware/Source-1-Games/issues/618
Seriously, could you give any background information at all instead of just posting a link to a bug report with a single, uninformative comment which links to another bug report which is like "Ooookay.."?
-
@morbiuswilters said:
@Ben L. said:
https://github.com/ValveSoftware/Source-1-Games/issues/618
Seriously, could you give any background information at all instead of just posting a link to a bug report with a single, uninformative comment which links to another bug report which is like "Ooookay.."?
I posted a link to a "bug report" that has absolutely no information about what bug they're reporting. And in the style of the WTF, I gave no helpful information whatsoever.
The reporter helpfully gave the name of the product, at least. And a link to a 6-minute-long video of them starting and playing through a quarter of a game.
The first 2 and a quarter minutes consist of them starting the recording (which they obviously didn't edit in any way), starting Steam, starting HL2:LC, and loading the map.
As soon as the map is loaded, they spin around and walk as far as they possibly can into the scenery. Then they pick up a crate, drop it, and walk back to where they started.
Then they climb up on a rock and shoot at the sand.
At 3:45, they reach the dock, which is right next to the fucking start position. At 4:17, they go further onto the dock. At 4:25, they walk back to the start of the dock.
If you watch until the end, you've seen at most one frame of helpful footage: the fisherman standing at the near end of the dock while the player is at the far end. The bug reporter could have posted this image, or even the sentence I just wrote.
No. They posted a link to a video that shows a known bug (original bug posted 2 days ago, this report posted 4 hours ago) plus 6 minutes and 16.999999999999999 seconds of pointless bullshit.
Here's the sad part: This isn't their first bug report.
In that one they posted 7 days ago, they included a screenshot and a description of the problem. They messed up the name of the map, but that's forgivable BECAUSE THEY ACTUALLY GAVE INFORMATION.
-
@Ben L. said:
Here's the sad part: This isn't their first bug report.
I work with 200 people that can't report a bug properly. The people I work with seem to focus on providing proof that the bug actually happened rather than information that could actually be useful fixing it.
A typical day for me: a bug report comes in with nothing but a screenshot and a vague question like "Have you seen this before?". I send the user "yup, it's been reported many times over the years, but we can't reproduce it, so it hasn't been fixed yet". A few hours later, I get three screenshots of other people with the same error message. I ask what they were doing when it happened. None of them can remember. I close the bug as "cannot reproduce". They go screaming to their boss that IT is ignoring them again, and send him the screenshots. I mention that if I can get steps to reproduce the bug, then I can fix it quickly. Without steps, I have to find it before I can fix it and I already spent four hours looking and I can reproduce it. Usually, I never hear back until the cycle starts again.
-
@Ben L. said:
The reporter helpfully gave the name of the product, at least. And a link to a 6-minute-long video of them starting and playing through a quarter of a game.
Wow sounds like a laugh-a-minute thrill ride.
-
@Jaime said:
I work with 200 people that can't report a bug properly.
I'm a school netadmin, and I work with teachers who remain chronically incapable of reporting issues properly. When I first started doing this job I used to get irritated by mails saying things like "Microsoft doesn't work in the lab", until one day I worked out that I can't teach kids properly.
These days, my standard approach to problem reports from people with a history of being vague or misleading is to go talk to them face to face instead of wasting time on guessing what their mails might mean. And every now and then this will alert me to other stuff that's been broken for months, usually with a trivial ten-second fix, that they have just been putting up with and working around without having made any attempt at all to bring it to my attention.
In IT support it's easy to lose sight of the fact that what we do doesn't actually matter very much to most people until five seconds after it really, really does.
-
@flabdablet said:
@Jaime said:
I work with 200 people that can't report a bug properly.
I'm a school netadmin, and I work with teachers who remain chronically incapable of reporting issues properly. When I first started doing this job I used to get irritated by mails saying things like "Microsoft doesn't work in the lab", until one day I worked out that I can't teach kids properly.
These days, my standard approach to problem reports from people with a history of being vague or misleading is to go talk to them face to face instead of wasting time on guessing what their mails might mean. And every now and then this will alert me to other stuff that's been broken for months, usually with a trivial ten-second fix, that they have just been putting up with and working around without having made any attempt at all to bring it to my attention.
In IT support it's easy to lose sight of the fact that what we do doesn't actually matter very much to most people until five seconds after it really, really does.
I have a friend who used to run a Minecraft server host. You know, that game where every 8-year old "runs" their own server? One day I sent him an email with a blank subject:
help it is breaked
Apparently that was more coherent than 90% of the support tickets he was getting.
-
@Jaime said:
I mention that if I can get steps to reproduce the bug, then I can fix it quickly. Without steps, I have to find it before I can fix it and I already spent four hours looking and I can reproduce it.
Does the program not have any kind of error logging, with the stack trace when the error occurred, etc?
From the sounds of it, the program is throwing up completely meaningless error messages with no information of any value to either the user or the developers, and neither is anything being logged anywhere.
That is a far bigger WTF.
-
@Daniel Beardsmore said:
@Jaime said:
I mention that if I can get steps to reproduce the bug, then I can fix it quickly. Without steps, I have to find it before I can fix it and I already spent four hours looking and I can reproduce it.
Does the program not have any kind of error logging, with the stack trace when the error occurred, etc?
From the sounds of it, the program is throwing up completely meaningless error messages with no information of any value to either the user or the developers, and neither is anything being logged anywhere.
That is a far bigger WTF.
Nice guess, but completely and utterly wrong. I love to start conversations with people who assume I'm a complete idiot before hearing the facts.
The program logs complete stack traces and even screenshots. The problem is that any bug that's simple enough to be solved with only a stack trace was solved a long time ago. All of the bugs that remain in production are difficult to reproduce.
That's a recurring WTF of its own. I'll often go through the error log and fix fallout from the last round of enhancements. When I try to get the bug fix tested and rolled out I often get into a conversation like this:
Me: "I have a bug fix that need to be put on the schedule to be tested. Here's the <<insert standard document name here>> document.
Them: "Where's the requirement?"
Me: "Bug fix, no requirement"
Them: "Who reported it?"
Me: "It was in the error log, Bob Jones experienced it at 12:34 last Tuesday".
Them: "We called Bob Jones, he doesn't recall then bug"
Me: "OK, well I can show you how to reproduce it"
Them: "Doesn't matter, we can't roll out a fix until the business reports the problem"
-
But yet, somehow, you still have no idea what the error means?
-
@blakeyrat said:
@Ben L. said:
The reporter helpfully gave the name of the product, at least. And a link to a 6-minute-long video of them starting and playing through a quarter of a game.
Wow sounds like a laugh-a-minute thrill ride.
That's six laughs, which is a very respectable amount for a single WTF. Good work, Ben!
-
@Daniel Beardsmore said:
But yet, somehow, you still have no idea what the error means?
If it's an error in some business logic, and not something that crashes and produces logs, how would you know if the users can't explain when the problem is?
-
@boomzilla said:
If it's an error in some business logic, and not something that crashes and produces logs, how would you know if the users can't explain when the problem is?
You mean, a business logic rule that generates an error that doesn't indicate what's actually wrong? What's the use in even having a message that doesn't tell someone what the problem is? Sadly, useful error messages are rare.
-
@Daniel Beardsmore said:
@boomzilla said:
If it's an error in some business logic, and not something that crashes and produces logs, how would you know if the users can't explain when the problem is?
You mean, a business logic rule that generates an error that doesn't indicate what's actually wrong? What's the use in even having a message that doesn't tell someone what the problem is? Sadly, useful error messages are rare.
"Fisherman stands at end of dock and ignores player."
-
@Daniel Beardsmore said:
@boomzilla said:
If it's an error in some business logic, and not something that crashes and produces logs, how would you know if the users can't explain when the problem is?
You mean, a business logic rule that generates an error that doesn't indicate what's actually wrong? What's the use in even having a message that doesn't tell someone what the problem is? Sadly, useful error messages are rare.
OK, I guess Jaime did refer to an actual message. I get stuff all the time where there's no message, but users think the system should have done something differently. Though sometimes it's very difficult to find just the right combination of circumstances to trigger something, and it's not always easy to figure it out if the user can't help you.
-
@Jaime said:
The problem is that any bug that's simple enough to be solved with only a stack trace was solved a long time ago. All of the bugs that remain in production are difficult to reproduce.
Or they no longer exist.
We maintain a client's system that sends realtime alerts to users via popup notifications; when they accept a notification it opens up an incident from that alert. Multiple users were getting an alert for the same ticket; they couldn't repro it at will, but a high-up in the business was shouting for the issue to be fixed. We looked at that part of the system, figured out it was actually broken, and rewrote it over the course of 2 months. Everyone, from us devs through to the testers through to the business users, tested it exhaustively and signed it off. Everyone agreed that the bug was fixed.
Yet months after the fix had been deployed, we were still getting reports of duplicate alerts. So we spent another entire month adding gradually-more-verbose logging to the system... which showed absolutely nothing wrong.
A month later we flew up to the client to assist them with a data migration. While there, we decided to speak to the business high-up who had originally reported the issue, and was claiming it was still present. After a 5-minute chat with him, we ascertained that the issue was resolved; he was complaining about a DIFFERENT issue, but our client's awesome devops team had never bothered following up to find out what it is, they'd just assumed it was the same one that had taken 2 months to fix.
tl;dr We wasted an entire month of dev time adding and reviewing logging for an issue that didn't exist because devops didn't do their goddamn job properly.
After this was revealed to the client's development manager (who has to approve budget for development), the directive came down that in future, all bugs logged MUST have a guaranteed repro or they wouldn't be allowed to filter through to the devs. Of course, the first time a business high-up shouted about a "bug" important to them, this policy went out the window - but it was nice for the week that it lasted.
The client's dev manager subsequently had a nervous breakdown and quit. 2 months later, they still don't have a replacement. But the same incompetent devops guys are still there, hard at work filing bugs that they can't reproduce. My strategy for these nowadays is to work on bugs that do have a repro; by the time I've cleared out all those, the un-reproducible bugs are so old that no-one remembers what they're about, so they get closed. A week later, a new ticket gets opened with a similar description... and so the cycle of failure perpetuates.
-
-
@flabdablet said:
These days, my standard approach to problem reports from people with a history of being vague or misleading is to go talk to them face to face instead of wasting time on guessing what their mails might mean.
This. I'll get an email or phone call, "HALP, thing is broken/doesn't work!" Rather than beating my head against the wall trying to figure out what the hell they're talking about, I just walk over to their desk and ask them to show me how it's broken. Usually it's quicker and less painful. Unless it's a remote issue. Then the real fun begins.
-
@Jaime said:
I love to start conversations with people who assume I'm a complete idiot
You talk to yourself a lot, do you?
@Jaime said:
before hearing the facts.
I will not that you are complaining, on the one hand, about users not sharing the facts, while on the other hand, calling people names because they do not have facts that . . . you did not provide them.
Irony, thy name is Jamie, and it's spelled stoopid.
-
@mikeTheLiar said:
Rather than beating my head against the wall trying to figure out what the hell they're talking about, I just walk over to their desk and ask them to show me how it's broken. Usually it's quicker and less painful.
When I do that, about 9 times out of ten, whatever isn't working starts working as I'm walking up. I keep telling people that's because I'm so smart, when I walk by, other people get smarter. (I wish I weren't the only one immune to the effect.) This morning, someone got smarter because I was thinking about walking up to her desk.
I'm not sure what's the WTF, there, that they're starting to believe me, or that I'm willing to let them.
-
@taustin said:
When I do that, about 9 times out of ten, whatever isn't working starts working as I'm walking up.
One of my favorites is the printer. It's got this feature that when it hasn't been used for a while it goes into this strange sort of stand-by mode, where it looks like it's on, but it won't actually do anything until you wake it up - which is indicated by the fact that the "Start" button, which is a least two inches across, is blinking incessantly. This happens a least once a week:
"Mike, the printer's not working."
Walk 15 feet to the printer and notice giant blinking light. Wordlessly push "Start." Printing commences. Give a look which is simultaneously smug and pitying. Turn and exit.
-
@joe.edwards said:
@The_Assimilator said:
[We have a dedicated, if incompetent, devops team]
I'm still jealous.It's all fun and games until one of them gets hold of a SQL script we devs wrote to fix a problem, and run it for a similar-sounding-but-totally-different issue. Then it's 2 weeks of trying to unfuck their fuckery. Bonus rage points when the one who does it is a "certified DBA" (this is why I don't put any faith in IT certifications). The system worked far better when we devs had access to live and did everything so they COULDN'T fuck things up. Yes, I know doing things (a) on live (b) by a dev is Bad Form, but we devs have an advantage when working on live: we actually check our shit before we run it. For them, it's "oh let's run this script, if it fucks up the devs get to fix our shit".
As far as I'm concerned, devops is where the people who are too dangerous/stupid/incompetent to be developers end up. Which is unfortunate, because the correct place for them to end up is out of the IT industry. Forever.
Oh and I did mention it's the client's devops team. Which ensures we usually can't complain about their incompetence, and when we can and do, nothing happens. Because our client, like all multimillion-dollar corporations, got there by hiring the lowest common denominator and paying them the lowest wage possible. And they wonder why their competitors are doing better than they are.
Aside: morbs, I read the comic... thing you have linked in your sig and now I have cancer, AIDS, and ebola. You should probably put a warning of some sort on there.
