Dear Ladies and Gentlemen,
Our company has been a loyal Infragistics customer since 2004. Currently we have 2 subscriptions with Standard Support and 1 with Priority Support (recently upgraded our application to 8.1).
Infragistics Support disagreed with me about what actually the responsibilities of the Support are. I’ve tried to contact DS Manager and Product Manager. My email was ignored by both of them.
I hope that this forum is better monitored and I can receive answers to my questions. For documentation purposes: my email to DS Manager and Product Manager was sent on 28.02.08. Original issue was the incident UWG28711. We have already worked around this specific issue (without whatsoever assistance or willingness to assist from the side of the support), so please don’t waste time with the solutions for the original incident.
I have two questions. The first one:
Infragistics Support holds the position that customers must provide a complete Visual Studio solution for reproducing of the bug where the only action needed on the support side is to open the solution, press F5, the bug will be reproduced automatically – solution can be passed to the development department.
I’ve already had several conversations like:
Andrej Kuklin: I bind a System.Data.DataSet to a WinGrid using SetDataBinding() method. InitializeRow event won’t be thrown. I’ve debugged Infragistics code, and the problem is a failed debug assertion. Here is the _stack trace_ to the failed debug assertion. Unfortunately I cannot reproduce it in a sample application. I can provide more information if needed.
Support Engineer: No sample means that problem doesn’t exist. May I conclude the session?
Question: Is this behavior also the official position of Infragistics? What are actually the responsibilities of Support Engineers when customer has found a bug in the Infragistics Controls? If the only responsibility is to press F5 in Visual Studio may be it should be better to rename “Support” into “Stub Proxy to Development Department”?
Second Question:
Sometimes I would like to know what other similar incidents were already registered (in order to check for workarounds or narrow down the possible source of the error). A couple of times Support Engineer didn’t provide me the information with the explanation “Sorry as per our support policy i can't provide you the incident or bug report number” (I’m copying from the chat log).
Other Support Engineers don’t have any problems providing me this information. My personal opinion is that it is pretty stupid not to give out this information because it anyway doesn’t contain any personal data, and this information is too precious to keep it not available to other customers experiencing the same problems.
What is the official position to this point?
Sincerely,
Andrej Kuklin
Andrej,
Thank you for your message.
You mentioned that you sent a message to DSManager (myself) and our Product Managers on February 28. We had an email server crash on February 29, and lost some emails from late morning on the 28th through approximately noon on the 29th. I don't have a copy of the message you refer to, and neither do our product managers, so I assume that these messages were lost in this crash. This is why you didn't receive a response from me earlier.
To address the specific questions you've asked:
"Is this behavior also the official position of Infragistics?"
Stated as you have above, no. At no point does Developer Support believe that a problem is not occurring simply because we don't see it. Our assumption instead is that we don't have enough information to be able to see the problem for ourselves. I'll touch more on this as part of the next question.
"What are actually the responsibilities of Support Engineers when customer has found a bug in the Infragistics Controls?"
We need to identify the circumstances that make the problem occur, based on information provided by the reporting customer. This is easiest when the customer provides a sample application, but if one isn't available, the Developer Support Engineer will attempt to create a sample application based on what we know. We may need to pass this sample back to the reporting customer for further information or modification, if we can't reproduce the problem with what we know. We may also need to trim down any sample provided, so that we can be better certain of what circumstances cause the problem - the less complicated the sample is, the easier it is to investigate and eventually fix. Our immediate goal here is to identify the property, control, circumstance, event, action, or combination of multiple such items, that cause the undesired behavior.
Depending on the nature of the problem, we can then look for a workaround, or possibly an actual solution, that doesn't involve changing code for our product. If there's still a problem that needs further attention, we log a development issue, which our developers use to determine if there's a bug, and fix it if possible. If there is a bug, a sample is almost always vital - not to confirm that a problem exists, but to better understand what needs to be fixed, and more importantly, to confirm that the problem no longer occurs once we apply a fix.
A stack trace isn't usually helpful for Developer Support to identify the cause of a problem. In the vast majority of situations, there may be countless ways for a particular stack trace to occur, and there's no way to tell what's actually happening without additional context. The same holds for a failed debug assertion, since it only tells us that something unexpected happened, not what made it happen. It'd be wrong to say that this information is "never useful," because there are times where a stack trace or failed debug assertion provides enough information for us to identify a familiar problem - but it is accurate to say that these situations are rare.
In short: If you can't reproduce a problem in a simple application, we'll do our best to reproduce the problem ourselves. If we can't reproduce, we will need to ask for more specific information or assistance from you.
"Sometimes I would like to know what other similar incidents were already registered.... What is the official position to this point?"
I see nothing wrong with Developer Support providing incident numbers or development issue numbers regarding simliar issues logged by other customers. As you've noted, this doesn't provide anyone with personal information, so there's simply no reason not to. This is likely a misunderstanding of procedure, and I've clarified this with my staff.
Please feel free to again contact me at dsmanager@infragistics.com if you have further questions or comments; this remains the most efficient way to get in touch with me. If I don't respond within a few days (as happened with your original email message), feel free to send me a follow-up message, or to post to the forums as you've done here if you feel it appropriate.
@informed_direct
Hi Rob,
I've read your story at "Infragistics Bloated and Horribly Written?" (http://forums.labs.infragistics.com/forums/t/1394.aspx?PageIndex=1), and I have the same strange feeling that the customers are the only ones who are interested in fixing bugs in Infragistics code.
"I hope that was a paraphrased response..."
Yes, I paraphrased his answer. But the exaggeration was not too large. Almost complete log looks like this:
========================
Andrej Kuklin: Environment information. I want to report a bug when binding a filtered dataview to a wingrid. It is a failed debug assertion which prevents InitializeRow to fire. But of course the failed assertion itself is also a bug. I've a debugger right now stopped on the line with the assertion. If you have any questions - you're very welcome to ask them now
Andrej Kuklin: Stack trace
Support Engineer: A couple of similar incidents/bugs which may be relevant to the issue
Andrej Kuklin: I've checked the description of provided incidents. Unfortunately, nothing relevant. Either too old for our version or not our scenario
Support Engineer: i need the complete description as to what is casuing the issue at your end, what type of errors are you getting, all this and more can only be achieved if i look at the sample
Andrej Kuklin: I think I've provided all directly relevant information. If you need more data - feel free to ask. I will provide any information you need
Support Engineer: When i use: ultraGrid1.SetDataBinding(ds, dt.TableName, true); I am able to fire the ultraGrid1_InitializeRow event for every row. If you want i can send the sample to you
Andrej Kuklin: Correct. There must be some extra conditions which lead to the bug.
Support Engineer: I hope you understand that until I am able to reproduce the erroneous behavior at my end I won't be able to get to the root cause of this issue and provide you with a proper feedback.
Andrej Kuklin: If you want this bug to be reproduced, you can very probably read some evidences in the stack trace. You're also welcome to ask for more information, if you need. I'd like to state it one more time clearly: it is a bug, I'm able to reproduce it, you have the stack trace as a proof that I'm not dreaming. I will not accept "Not reproducible" resolution
Support Engineer: But i am able to fire the ultraGrid1_InitializeRow using SetDataBinding and DataView i cant submit it as a bug without having replicted at my end. You can check the sample and modify that using the code that you are using at your end.
Andrej Kuklin: I know that the event will (and according to specification should) be fired. I _do not need_ working samples. I _know_ there is a bug. You have a stack trace, you have a failing debug assertment, you have a description. Go and make a sample, if you need it
Support Engineer: I have tried all things at my end and i cant say what is causing the issue at your end. Please modify the sample or send me an isolated sample. this is the nearest what i can do for you.
My perception of the situation was that the Support Engineer was absolutely not interested in fixing the bug. He was interested in getting rid of me. I had the situation reproduced with the debugger attached to the application. The bug was without any problems reproducible on my side. But still nobody asked to take a look at some settings (what kind of filters are defined on the dataview) or check whether there are DBNull in the data. BTW, I still don't know what the cause was. At the end of the day we have rewritten our control and somehow worked around the issue.
@Vince McDonald
Hello,
I must be a very "lucky" guy or your mail servers have developed some kind of intelligence against such troublemakers like me :). It is the second time I try to escalate the issue to DSManager/Product Manager and the second time my message is lost because of technical problems (the first issue was WTB4415 "UltraToolBarsManager corrupts the resources in other languages". This issue seems to be solved in Visual Studio 2008 now). Anyway:
1. Thanks for clearing the issue "providing incident numbers regarding similar issues logged by other customers".
2. I will resend you my original email with the chat log.
Vince, one of my reasons convincing our management to pay for premium support was that we'll actually receive better support. And I will be able to spend more time doing code reviews with other two UI developers, designing our controls, providing added business value to our customers. Actually nothing has changed with the support after that. Except that now I receive the phrases "Unfortunately as such there is no such intrinsic functionality available" and "Please send me an isolated sample" not per email but in the chat window.
My primary goal is to provide the best user experience to our end users and to help them to solve their business tasks. Given the rich functionality (comparing with other products) NetAdvantage components are best suitable for that. On the other hand given outdated and simply wrong samples, absent documentation and pretty poor (IMO) support my employees and I myself can't efficiently use the components because we need to spend enormous amount of time figuring out how to make this or that feature work, identifying and working around the bugs (which are not really rare unfortunately).
Once again, my intention is not to accuse anybody. I just want to know whether Infragistics is going to invest in these areas and improve support, samples and documentation. If not - then it would be probably better for Infragistics to get rid of troublemakers which demands don't correspond with the strategic vision of the company and for us - to pick a more quality-oriented vendor. Of course we can't move our product in a week to new components, but at least I will budget the costs for doing that and make appropriate plans for our next release.
(BTW, I know there is a person which is solely responsible for the documentation. I now even receive responses when I email the documentation issues with "E-mail your feedback on this topic" link, but apparently he/she didn't have a chance to improve something significantly for 8.1 documentation).
I've read the chat log you've quoted in its entirety. There are certainly some things that could have been handled better on our end. Our next course of action should have been to send a sample of what we had, so that you could compare what our sample was doing to what your application was doing. This way, we'd learn something about the nature of the problem, and would have a better chance to ask questions that would lead us closer to a solution for your problem - which is our main priority.
Our priority support guarantees to return a response by 5:00 PM Eastern Time to a support request received before 1:00 PM Eastern Time. For support requests received on or after 1:00 PM Eastern Time on a standard US business day, a response will be returned by 1:00 PM Eastern Time the next standard US business day. Priority Supports also gives you access to phone and live chat support.
Our primary goal at Infragistics is to delight our customers. We have begun to implement changes, such as adding more resources and investing in advanced training across Developer Support, Development, Documentation, Quality Assurance, and other departments to ensure that our customers always have a positive experience with us. We will continue to work as a company to improve all aspects of our product and support. Feedback from our customers, such as what you've provided here, is an integral part of that improvement process. Thank you for your feedback and patience.