- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Ohgreat.Nowthedarnspacebarwon'twork.
Admin
So your solution is to encourage the clueless idiot?
Admin
Do the developers get dinged for having too many open tickets, or for having a ticket open too long? If not -- if tickets are purely a communication and record-keeping device between support and development -- then as others have said, the developer could just have noted in the ticket that the problem was a broken printer and left it open until the printer was repaired or replaced. If that was the situation, then he was just being dumb to make a big deal of it. Who cares if support doesn't understand the root cause of the problem? Just leave the ticket open until the problem is fixed, whatever is required to get it "fixed".
But if the ticket system IS used to "score" the developers, that's a different story. I used to work for a company where various top executives would get a regular report on how many open tickets there were, how long they'd been open, etc and then they'd yell at the project teams for having all these open tickets. It did no good to point out that the ticket was still open because the customer had never replied to a request for more information, or that a fix required a decision about requirements and we were still waiting on a decision from the same manager who was now yelling at us for not getting the ticket closed, or that we had been told not to fix that particular problem because the system was was being replaced by the new-and-improved whizbang system and so it wasn't worth spending time and money to fix it (even though the new-and-improved whizbang system is five years behind schedule with no end in sight), etc etc. Thus there was constant pressure to close tickets, even if the issue was not really resolved. We had to find some justification to close the ticket.
This is a subset of that whole large category of things that are really good when used as a day-to-day working tool, but that become counter-productive when used as a personnel management tool. Because once the tool is used to evaluate the productivity of employees, the employee's incentive shifts from being "keep the information as accurate as possible" to "keep the information as favorable to me as possible".
Admin
That is unless the employer has some draconian policy against ignoring bugs, regardless of the idiocy of its contents.
Admin
Yeah I suppose... but then that's a WTF in itself.
I'd have still just ignored it, and waited until the draconian policy asserts itself, then tell the draconian policy enforcers that I already resolved it, provide them with the evidence, and then give them directions to Alan's desk.
I'd probably also offer them one of the lovely biscuits I got from the kitchen, along with a friendly smile.
Admin
There's too many comments saying it to pick one to reply to, but for those stating it should have been left open and/or handed off to the "hardware support", I got the impression that this company simply sells software. So it would be like, as the developer noted, calling Microsoft to open a ticket with their support and expecting them to keep it open until you get the new printer. If this company does also support the printer then yes it's just a matter of reassigning it to the correct person. If not then there's no reason whatsoever to keep it open.
Admin
I would have left it open and never closed it. Fuck em
Admin
Admin
Where is Steve the Cynic and his GAU-8?
Admin
This is possibly the result of a long history of the IT department forgetting to finish cases because of more urgent work, or ignoring cases and letting them silently disappear. Happens all the time where I work, and it's very irritating.
Alan H is certainly being a dumb ass here, though.
Admin
Admin
Admin
I like our (inhouse) bug tracker. It's got its share of WTFs, like not being able to set a new bug status if it hasn't loaded the list of possible statuses (~70) in another frame yet, but quite powerful.
In this case, I'd suggest the status 'Closed, environment issue'.
Admin
I'm sure someone has said this but I can't be arsed to read all of the comments:
The whole problem is that Alan H thought that the bug reporting software was issue-tracking software, or didn't know the difference; and Colin didn't explain the difference to him. Drives me crazy when poor communication yields counterproductive situations like this.
Admin
That is... a lot of statuses. Even if you only had one field, so "closed, fixed", "closed, duplicate", and "closed, not a bug" were three statuses, rather than the logical implementation where "closed" was the resolution and "not a bug" was a separate status... we'd still only have 36 "statuses" under that system, and it's pretty rare that that doesn't cover all our needs. New/confirmed/assigned/resolved/closed, coupled with not fixed/fixed/not a bug/duplicate/can't reproduce/won't fix (usually means "a bug, but not -our- bug, bother the software whose bug it is." Occasionally means "not worth our time.")
Admin
Admin
Can I apply for a job in your company?
Admin
What we've got here is failure to communicate. Some men you just can't reach. So you get what we had here last week, which is the way he wants it. Well, he gets it. I don't like it any more than you men.
Admin
That, and variations, and enhancements/doc bugs are tracked via separate statuses (though those lists are smaller).
Admin
Better to have the customer spend 2 hours over 20 phone calls than to have a single 15-minute call.
Admin
I get the feeling that these two people have a history. I bet they even avoid eye contact with each other.
Admin
As a software developer, I've had my share of such "bug" reports. Fortunately, I've never had to deal with someone like Alan H., and "hardware issue -- not a bug" was usually sufficient to have the item remain closed. Sometimes, a brief description of why it was a hardware problem was required, but that's it.
Example:
"Bug":
Vertical lines on graphics boxes on ${TERMINAL_MODEL} are not connected.
"Solution":
${TERMINAL_MODEL}'s graphics character set draws vertical lines with gaps. Not a bug.
Admin
For many years at the company I work with now, the home-grown helpdesk application also did double-duty as the software feature and defect-tracking system. Among other abominations, this led to any open issue on a program (feature request, bug, cosmic disaster) being referred to as a 'point' (i.e. 'that is one nasty point you have open in the Checkout program), because 'Point' was the label used by the original programmer on the issue reporting form. Thankfully, this system has been long retired, although some of the old-timers will still sometimes forget themselves and refer to bugs as 'points'.
I'm guessing that Colin is fighting a losing battle with a similar system; a catch-all program that logs everything from new furniture requests to the development teams plans for bringing about the rise of Skynet. After all, it worked when there were only 20 employees in the company; why shouldn't it work just was well when there are 1000?
Admin
Admin
One lacks mental skills, the other lacks social skills. Why hate on one over the other?
Admin
Get real. You can't set a ticket "resolved" unless the issue has genuinely been resolved - in this case, by the new printer being installed. Once the customer has acknowledged that the issue has been resolved, then and only then do you close it.
Colin is not a prick. He's an utter fucking cunt and he ought to be flying out of the door at a sizeable fraction of the speed of light. A complete fucking shithead.
Admin
Admin
Not sure if troll...
You can set a bug "resolved" if the issue is not a bug in the product, your bug tracker is intended to track product bugs, and there is a completely different system (note "An issue was raised with IT Support Desk (SUP88373)" for tracking customer support requests. You generally do so with a substatus like "Can't repro" or "External".
The bug was properly resolved. Alan H should have immediately Closed it, and tracked the status of the customer's printer acquisition through the appropriate channel.
Admin
We are doing this on a whiteboard and we come and click photo of it with cellphones.
Admin
Wouldn't you hate to be that customer who keeps getting pestered about his broken printer?
Admin
If I immediately received another call after the previous call ended, I knew customers were on hold waiting for the next available CSR. But if there was a longer than 10 second pause between calls, I knew that person had just barely dialed in. So, I would pick up the call and then hang up on them. I assumed they would figure they dialed wrong or something, and probably just dial back in. I didn't do it on back to back calls, in case it was the same person, and really I didn't do it that often. But five 1 second calls grouped with 45 120 second calls was enough to keep me at the top of the rankings.
Admin
Clearly the written medium is failing to communicate correctly causing confusion.
fortunately I have a piece of equipment on my desk that can usually solve these failures is a mater of moments
What is it? A Telephone!
"Its Good to Talk!
Admin
The company I work for has a unique (I hope) system for preventing tickets from staying open too long. The ticket must be updated at least once a week. Not just any update will do, however. The "Waiting on" field must be reassigned between support and the user. If internal support is waiting for an answer from the software vendor's tech support, the internal support must still reassign it to the user, even though it isn't waiting on the user.
What happens if the ticket goes a week without playing this little game? Does the ticket get escalated because it is taking too long to resolve? Noooooo.... The system assumes that if the ticket hasn't been updated, that the user no longer has a problem, and automatically closes the ticket.
Admin
Would you prefer "Cancelled - not a bug?" Because if it's been logged as a software defect but found to be a hardware problem, we'd cancel it in an instant. They can re-open it if the problem persists after the hardware is replaced...
Admin
Oops ... wait ...
Admin
If that was the case, then Alan H should have logged that in the ticket. Anyone who reopens a ticket without at least the courtesy of saying why, or replying to the answers he has been given, is an idiot.
Admin
Actually, I find that the modern telephones aren't really heavy enough to crush the skulls of my nemeses (sp?). That's why I keep a cricket bat on my desk.
Admin
Admin
Reminds me of the few occasions I hard to work with an Aspie.
Pray that someone else tells you about the condition before, otherwise you will get in very, very awkward situations.
Admin
Admin
there are 2 possible reason why Alan behaves that way:
A) Alan H is an idiot who don't even look through the ticket history before re-opening the ticket or call the customer for follow up. There are more of such people on this planet than you think.
OR
B) Alan H is required to follow up the customer after ticket is closed and is required to re-open the ticket if the issues is not resolved.
I agree with previous posts, the real WTF is the communication skills for both parties involved and the management's idea of performance tracking via the ticketing system.
Admin
And don't forget about the chain of emails all of which have "This communication, including any attachments, may contain information that is confidential and may be privileged and exempt from disclosure under applicable law. It is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender. Thank you for your cooperation." (which no one trims off either?) (Like that sentence carries any legal weight with it anyway, it's a waste of electrons.)
Admin
We had a bouncing bug like this with one of our customers. We'd introduced a new version of an application to be compatible with their new (completely incompatible) back-end system. They raised a bug that, when the thin-client software was restarted, it didn't go back to the main menu. The tester insisted that the old software had done this - even though the application was designed to, and had always, directed the client back to the same screen that the user was on when it was closed down.
The tester would absolutely not accept that this was the case, but refused to actually compare it to the old system, and refused to close it. So we had this bug hanging around and being mentioned in conference calls, until it was the only unresolved bug left. Eventually the customer's project manager accepted that it was not actually a bug and stopped mentioning it, but it's still open in their bug tracking system as far as I know.
That project manager has now left, so I live in fear that the zombie bug will one day come back to haunt us...
Admin
Admin
I had a similar experience, but rather than get angry I gave the guy a time-out.
Admin
You just always give that one bug to the FNG to test their people skills until one of them succeeds.
Admin
Unfortunately, this sounds a lot like the thought processes of our help desk...
Admin
Wow, wonder if we worked in the same place. Or perhaps Microsoft managed to sell that SCSM system to some other poor bugger as well.
Captcha: Eros... Definitely not something I'd normally associate with SCSM.
Admin
Admin
So many nice people... If I was there it would end like that
IF YOU REOPEN IT AGAIN DI**T I'LL COME TO YOUR OFFICE AND START KICKING YOUR HEAD UNTIL YOU FIGURE OUT HOW TO THINK WITH IT, NOT WITH YOUR A.