Feedback for IT

  • Comments posted to this topic are about the item Feedback for IT

  • 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, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • 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 Row-By-Agonizing-Row.
    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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

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

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

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

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

  • 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

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

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

  • A familiar story Steve; I've often experienced problems similar to your wife's. But when it comes to feeding this information back to the organisation concerned I try on three different 'hats':

    1) my tester hat: "it would be great to get this sort of direct feedback because it helps me to improve my test cases"

    2) my developer hat: "knowing this would help me to improve my code"

    3) my business analyst hat: "ah! a problem that we need to find a solution too. I know you coding guys love an SQL emergency but let's not jump the gun and assume it is a coding issue. It could be a simple data entry issue."

    In the end I always opt for the last approach: present the organisation with the actual user's problem as experienced, don't try to present a solution because, as 'CirquedeSQLeil pointed out, you don't want your staff deluged with false positives. As a developer I demand the same from my BAs: "give me a problem, don't tell me (what you think is) the solution".

  • Couldn't agree more, Steve.

    Two personalities in the SQL world, I'd most like to meet. Steve and Steve's wife!

    In France, where I live, (and I wouldn't be surprised if it was global) a majority of the major utility companies (especially internet service providers) go out of their way to make it impossible for you to provide any feedback.

    To cut their customer service costs, they oblige you to loop recursively around their online help. But when you're up against something not covered in the help, then there's often no way to email / telephone anyone or even fill in a form.

    There's an upsurge of 'virtual customer service assistants', where you see a slightly animated face stuck on top of a text box, inviting you to tell them about your problem. It reminds me of "English Query" in SQL Server some years back (where did that go?!)

  • LOL, that's funny. Actually a friend from the SQL world is coming to the SQL Saturday in Denver, and bringing his wife to meet mine 😛

    Some companies in the US had gone to online help, but that has started to switch as they realize they can't cover all bases. Google is the most difficult company I know, but they have some places you can send in a note and get a response, albeit slow. They get away with it because they're so large, but it's a crappy business practice.

  • To emphasize your point about a CS person passing along the note to IT. I had an issue with a certain brand router. Whenever there was a power failure or a firmware update some settings were lost. I opened a support ticket and asked them to inform their developers that said settings were not being saved.

    Instead of passing the information along they proceeded to follow the troubleshooting script when there was nothing that could be done. After 5 e-mails I just gave up and just ended up replacing the router.

  • I like to build in error logging/reporting directly into an application.

    If the application knows an error occured, it should log all pertinent info (depending upon the info, there may be some security concerns here) and report it.

    As a developer, I could often have a problem identified, fixed, tested and ready for roll-out to production before the help desk even knew there was a problem.

    Handling error reporting when the application doesn't know something is wrong is a bit harder. I would love an easy framework solution for that!

Viewing 15 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic. Login to reply