Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQLServerCentral.com
»
Editorials
»
Feedback for IT
15 posts, Page 1 of 2
1
2
»»
Feedback for IT
Rate Topic
Display Mode
Topic Options
Author
Message
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Wednesday, July 28, 2010 8:11 PM
SSC-Dedicated
Group: Administrators
Last Login: Yesterday @ 2:54 PM
Points: 31,410,
Visits: 13,726
Comments posted to this topic are about the item
Feedback for IT
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #960435
SQLRNNR
SQLRNNR
Posted Wednesday, July 28, 2010 9:49 PM
SSCoach
Group: General Forum Members
Last Login: Yesterday @ 1:07 PM
Points: 18,733,
Visits: 12,332
Nice hot button Steve. There needs to be some level of technical triage to scope out any actionable bugs. You wouldn't want your development and project management staff deluged with a bug tracking system that could be full of false positives or complaints about non-actionable items for IT.
Jason
AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008
SQL RNNR
Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #960454
Jeff Moden
Jeff Moden
Posted Wednesday, July 28, 2010 11:16 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Yesterday @ 5:33 PM
Points: 32,902,
Visits: 26,783
So how could you let IT know? You could call customer service, but I have a hard time thinking that a low-wage CS person would pass this along to the IT group.
I've recently had to work with an airline on a similar problem recently and there's not much difference between the low-wage CS person and the low-wage "third party" developer sitting in the same bloody cubicle which is why the error happened in the first place.
Send an email and hope everyone does their job. It's a whole lot less frustrating that way.
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #960488
Daniel Bowlin
Daniel Bowlin
Posted Thursday, July 29, 2010 7:09 AM
SSCrazy
Group: General Forum Members
Last Login: Friday, May 17, 2013 11:53 AM
Points: 2,672,
Visits: 2,416
Completing the feedback loop is probably one of the most difficult challenges for any business, business unit, or even local department. I used to work in a very small company where closing the loop meant calling one of the other 25 or 30 people in the entire company, and yet there were gaps in communication everywhere. Maybe this is the next big thing for IT to tackle, making sure all the mechanisms are in place to automate, or encourage this as much as possible.
Post #960680
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Thursday, July 29, 2010 8:38 AM
SSC-Dedicated
Group: Administrators
Last Login: Yesterday @ 2:54 PM
Points: 31,410,
Visits: 13,726
There might be low level developers, but if they triaged reports of bugs, at least it would be captured somewhere. I know in a company that employed 200 people that it might be better to have a junior dev picking through bugs for a few minutes every day than having large customers yelling at salespeople.
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #960757
Mike Dougherty-384281
Mike Dougherty-384281
Posted Thursday, July 29, 2010 10:00 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 9:54 AM
Points: 198,
Visits: 680
I think it's also important that developers build baseline diagnostic record into the app. We generally need some way to prove the code during development anyway, but those checkpoints should be built with the intention of being left in place for gathering statistics during normal operation. Then when issues of scale or new usage patterns develop there is a baseline from which to compare the new behavior. It's difficult to assess user complaints of "slowness" if operations complete in under 2 seconds - but if normal operation before some critical event was 0.25 seconds then its clear that an 8x lag is worthy of investigation.
I had a backup job recording start/stop/size with each nightly operation on 15 remote locations. When some of the backups were not complete by the start of the day, I checked the logs: throughput was down to 20% of normal. That was enough clue to look for what was consuming bandwidth overnight. 'Found two machines inside our network had become zombies/botted. I would not have even known to look for that if I hadn't been keeping logs/baseline to see the change.
Post #960845
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Thursday, July 29, 2010 10:05 AM
SSC-Dedicated
Group: Administrators
Last Login: Yesterday @ 2:54 PM
Points: 31,410,
Visits: 13,726
Good point, Mike. We need to have instrumentation embedded, and it needs to work. I used to complain about performance monitor dropping events. We need this overhead to be in place and accurate, especially under load, to determine what is happening.
Good logging and tracking is important, and tracking exceptions, like unexpected long processing times, is a great way to find issues.
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #960849
Phil Factor
Phil Factor
Posted Thursday, July 29, 2010 10:55 AM
Mr or Mrs. 500
Group: General Forum Members
Last Login: 2 days ago @ 4:00 AM
Points: 533,
Visits: 2,285
You might have thought that SmartAssembly, described here http://www.simple-talk.com/dotnet/.net-tools/smartassembly-eating-our-own-dogfood/ by Simple-Talk's editor, is a bit peripheral as it is designed mainly for .NET applications, but if you pore through the manual, you'll see that you can use it in an application in such a way that you can get the message right through to the devs (via an internet or email connection). It can be used for any error, even if it doesn't trigger an exception, and you can add the facility to let the operator or user provide as much explanation as they want, as well as the details, specific to the application, of what was actually going on. This can, of course, include the SQL. I can tell you that, when in a .net-based database application, smartAssembly can provide some very, very revealing information that can be embarassing for the devs, but which enables them to do the fix very quickly.
Best wishes,
Phil Factor
Simple Talk
Post #960885
bwillsie-842793
bwillsie-842793
Posted Thursday, July 29, 2010 1:01 PM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Friday, April 12, 2013 7:43 AM
Points: 107,
Visits: 287
I like the "Click here if you have a problem" button right on the user interface screen. No doubt you will get a bunch of crap in a public environment, but if you put in some filtering it can be screened out.
Having run a Customer Service center for a small manufacturer, I now go out of my way to give feedback to companies- both good and bad.
I am amazed at the number of employees that do care, but don't know how or who to pass issues along to in their organization.
Post #960964
deanroush
deanroush
Posted Thursday, July 29, 2010 2:31 PM
SSC Rookie
Group: General Forum Members
Last Login: Thursday, May 02, 2013 9:10 PM
Points: 26,
Visits: 263
I actually had a menu choice on my desktop app's help menu that would allow users to send messages directly to the software developers. After two years of no messages, I removed the feature.
Steve is right about logging. We log everything the users do in an app to a table and then analyze it periodically to see what they are doing most/least frequently, warnings, errors, etc. to see where improvements are indicated.
Post #961021
« Prev Topic
|
Next Topic »
15 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.