Getting ASP.NET programming lessons on the quiet

21 August 2007

A conversation I had recently turned out to be funny; not funny ha-ha per se, more funny amazement.

I was chatting to Plato, a member of our support team. He's taken on a couple more supervisory responsibilities since Max has been tanning himself on vacation at the seaside, and he showed me a reply that had been written to a customer. (I'm paraphrasing, by the way.)

"You must set the DataSource property of the ASPxGridView with every call to Page_Load, not just that first call with IsPostBack == false."

This stunned me: it implied that the customer didn't know the page cycle for ASP.NET applications, that they didn't know that everything has to get reconstructed (and destroyed) for every postback, that ASP.NET programming is just not WinForms programming, and that state is not maintained.

I was suddenly hit with a thought, and so I asked Plato: how many times are you helping people with our ASP.NET controls and it turns out that you end up helping them with standard ASP.NET concepts instead. He replied, every day. He gave the example of one customer who, despite several example programs or variations thereof, still doesn't seem to get the ASP.NET page cycle, the difference between server-side and client-side processing, but, because they're using our ASP.NET controls, we should be helping them.

This situation fills me with amazement and a bit of shock. We have a fixed set of resources for support: the guys in the support team. When one or more of them goes away on vacation or is sick the others have to take up the slack. And here they are teaching some customers ASP.NET programming by giving answers to questions and by providing example programs. All of this takes time, time away from other support issues and customers, those that perhaps require more advanced answers with longer research times.

And I'm shocked too: are people really approaching web applications as funny kinds of WinForms programs? Or are they being told by their bosses to "make this program work in a browser" and are thrown in the deep end, and have nowhere else to go but their control vendor's support team?

I remember when I started ASP.NET programming. I read through Fritz Onion's Essential ASP.NET cover to cover and I still got the cycle wrong in my first few attempts at writing a web app. And I was using Developer Express' ASPxGrid as well. But I persisted and worked it out and finally the page cycle became my friend. Do programmers these days not bother? Or are they hacking away in the hope that something works? And somehow we're getting caught up in this loop of hack, hack, hack?

I don't know the answers to these questions. I equally also don't know what to do about these under-the-radar ASP.NET tutorials that some customers are getting. Where is the line between helping with our controls and teaching about web programming? Should I even bother getting worried about this? A happy customer is a happy customer after all, even if we're making them happy by helping with some standard beginner stuff.

I've asked Plato to monitor the situation but I certainly don't want to get all bureaucratic and forbid it. Sigh, just color me amazed.

17 comment(s)
Steven Nagy

I have a few things in response to this:

1) When you have a product and you provide support, no matter what the context is, you will have to deal with problems that are outside the domain of your product. For example, I recently heard that less than 50% of triple-0 calls (the Australian equivalent to 911) are actual emergencies. I think that if you are in the business of products, then you have to provide support. I then think that if you provide support, you have to expect that sometimes the actual issue is not in your domain. But I still believe it is your responsibility.

2) The majority of developers and junior developers actually do not understand the stateless nature of the web and the ASP.NET lifecycle.

Solution? Well you can streamline the support process by:

a) Creating a knowledge base that deals with the common problems, and hotlink to those articles

b) Create default email template explanations, such that they look like a personalised reply.

Even though there is no fault with your product, you do of course still have a level of responsibility to your clients. As long as your not teaching them ASP101 I suppose.

22 August, 2007
Aaron T Fischer

I kind of assume its like thisfor most tech/software companies.  I know we do a lot of teaching basic windows networking so the customers can get our product to communicate.  And I have heard of a few lessons given on basic loan origination.  

22 August, 2007
Aaron Jensen

Hmm... kinda makes you think... maybe the whole Web Forms "abstraction" is just too complicated? :)

22 August, 2007
Rick

I like Steven’s solution A:

) Creating a knowledge base that deals with the common problems, and hotlink to those articles.

I am also going to say… if I was better than you, or your companies support and / or your companies products… I wouldn’t need them or you…

And remind me… what is your business?

"Sigh, just color me amazed."

22 August, 2007
Rollie Claro

I thinks that what makes DevExpress stand out of the others. keep it up.

throw in some "idiot's guide to ASP.NET" it helps sometimes.

22 August, 2007
Rick

Better include one for 'Windows Forms' too.

And... one on Bound Controls vs. Unbound Controls while we're at it... :)

22 August, 2007
Luc DEBRUN

I am one of those who have gotten a few VB.NET lessons on the quiet. So I would like to comment (apologies for the long comment).

You are in a business where you promise that buying your components (as opposed to those of your competitors) will allow us to write full apps in 15 minutes in time to get our hamburger. You do a good job in that business. As such, not all your clients are C# MVP. Some of them are not even programmers! I myself am a budget officer who has to write its own databases and reporting tools because of lack of funding. I recently switched from Delphi to VB.NET and once in a while I get stuck and I need help from Support. I try to limit my requests to support by various rule of thumbs and use the forum instead, but I do have the feeling that once in a while I do ask something stupid. (Feel free to review my records and come up with some data as what is VB question vs. Product question).

If I can suggest:

Through various posts over the years (3-4?) I have tried to impress on your guys that we (the non professionals) need code samples and more code samples in the help files. Each 'class member' should have at last 1 example of what can be done with it. Also the Task Help should grow and grow with more task articles with each major release. Finally, the code samples need the have a link to the completed sample project. For example, while I think you did a very good job with the help files of the RC1 for XAF, you should not stop there. The reply I received in the forum for the use of the XtraSpellChecker for example should make it in the doc at the next release. Every answer you give in support should be reviewed for inclusion in the help file. Basically, you are not making enough use of the time your staff spend in the Forums and support. I had also suggested once that instead of 4 majors a year you do 3 regular majors and 1 major help release with all the code you can put in. That will pay back.

If I can say one more thing:

I have tried various components suites out there and the support (that includes the occasional free lessons) provided by Devexpress is the best out there and that is why I stick like glue with you guys and pay up for the full subscription. Do keep up the good support.

22 August, 2007
Lars Black

Luc,

I'm sure you're right when you say that "Some of them are not even programmers!", but is that a problem of DevExpress? Their components are written "to help developers" as they write on their product page.

If I buy a new car, I expect the car dealer to tell me the things that are special for my new car, but not the basic traffic rules.

I appreciate that "developers-in-spe" has to start somewhere, but with all the ressources avaliable on the net today - most of them free of charge - I'd rather that DevExpress could focus their ressources on other things than learn people the basics of development for a given platform..

Cheers,

Lars

22 August, 2007
Tim Sullivan

This isn't uncommon at all. We frequently need to teach people basic Windows operations such as drag-and-drop and double-click vs. single-click, and even more advanced tasks like opening ports on a firewall or HTML editing.

This is the nature of technical support. There will always be people who don't fully understand what they're doing at a more fundamental level than the application or the toolset they're using. We can recommend that they get training as much as we want, but if we don't answer then our support "sucks".

22 August, 2007
Dallas Sehlhorst 1

I don't know, I'm on the fence with this one.  I don't think it is up to DevExpress to respond to basic ASP.NET responses, but at the same time I feel that paying customers shouldn't be left out in the cold.  DevExpress can't possibly "screen" its customers before they sell them a subscription, so they're forced to answer every question that comes in.

As for everyone saying that DevExpress has the best support out there, yet suggesting they add an extensive KB or an "idiot's guide", many companies already have such features.  And in my honest opinion, these other companies HAVE better support because of these extra resources.  I almost wish that DevExpress would "grow a pair" and only answer questions directly related to their product line- while suggesting that ASP.NET questions get asked in the forums.  This would give DevExpress more time and resources to answer technical questions from "real programmers".

Just my two cents though.

22 August, 2007
Shloma Baum

Julian,

As everyone else here, I agree that you cannot (if you want happy customers) respond to go look for other sources to resolve a issue, we as well have to train sometimes basic windows task for our clients.

Regards,

Shloma

22 August, 2007
Luc DEBRUN

Lars & others,

A few times, I had a little 'cold' reply from Devexpress. A recent one pointed me to a C# to VB translator, and a suggestion (geared to beginners) made in April 2006 (6!) is finally Accepted TBD since May 2007 (7)! Ok ... probably overused my support brownie points on those requests. :P You have to understand that sometimes we (less advanced users) think we ask a product question but it is really a VB, C# or ASP question.  And I believe it is ok for DevExpress to 'politely' redirect away or not prioritize such requests. Personally I wont get upset because I know there are others whose pay check directly depends on a fast DevExpress Support reply and I know I can be in the way. I sincerly hope that others asking stupid questions will behave the same and be humble enough to accept a 'cold' reply from Devexpress.

However, DevExpress advertizes their 'car' as being the easiest to use. And they advertize that for a flat fee, you can bring the car in the shop as many times as you want. They advertize that their car will make you win the 24Hours LeMan race. So there are a lot of drivers which dont know the basic traffic rules who buy their car. So in a way, it is a little DevExpress problem.  

They cannot avoid all stupid questions, but what I am saying is that a lot of basic requests could be avoided with more code samples which directly apply to DevExpress products (you dont find many of those in CodeProject or other places on the net).

Finally, I believe that less advanced users have a role to play. We tend to come up with a lot of suggestions for features which we feel should come up out of the box. That is because we would not be able to programme them ourselves so we have no choice but to ask Devexpress to do it! I could name several features I came up with and that are now in! :)

Isnt that worth a little understanding ? hm ?

Luc

Ps. I cannot praise Devexpress support enough compared to other companies I tried. Period.

22 August, 2007
Julian Bucknall (DevExpress)

All

I awoke this morning to some excellent responses to my post. Instead of replying to each and every one of them, let me aggregate.

You're all right of course: there's no way to separate support for our products from support for the underlying technology. The line separating them is not thin and well-defined, it is wide and fuzzy. I can't have the support team suddenly saying to a customer, sorry, your question is no longer about our control, you're on your own. Besides which, if I tried to implement such a rule, (a) the guys wouldn't do it and they'd tell me to go take a hike, and (b) the customers would raise a ruckus like you wouldn't believe and I'd be signing on the dole.

And, of course, we sell to anyone who wants to buy our products. There's no way we can (or want to) institute a multiple-choice test for potential customers and would only sell to those who got an A. We're well aware that our customers' expertise ranges from beginner through to expert. My "d'oh" moment was that I didn't realize that the support guys would help with basic questions about the technology.

Which is silly of me in a way. Back in the days when I worked at TurboPower Software and was doing tech support myself, I would help customers out with those "basic" questions that arose out of the use of our libraries. I should have remembered.

But that does raise the issue of what we can do to alleviate the problem. Luc, of course, is right: it behooves us to write more code samples, more tutorials, more simple demos of our products, that we can point to in order to help answer questions. And presumably we can also provide examples that, in using our products, would also answer questions about the underlying technology. We are slowly but surely adding more code snippets and examples to our help files, and we do have the online knowledgebase, but it's a long process. I've also tried to impress upon the developers that we can't issue a release of a new control without a good set of example code for it. The tech writers can only do so much.

Cheers, Julian

22 August, 2007
ctodx

To follow on from (and to complement) my post about us providing support for basic ASP.NET programming

22 August, 2007
Gary Gibbons

This is a very important blog post, and I think really is a bigger issue than some may realize.

I like this question; I’ve heard a fair amount of ranting about the lack of respect for those that don't have the latest CS diploma hanging from the wall, but are compelled for some reason to delve deep into things programming-wise.

The issue whether to include support for basic programming principles is nothing new, to be sure. Well, relatively speaking, since computer science and programming at the current level of technology hasn't had more than a mere few decades to mature.

Even the PhD’s in the field understand this limitation.

So what?

I find myself compelled by the very thing that doesn’t want me to understand it and use it.

It seems simple enough to understand that no comparison exists between entry-level knowledge, and post-graduate course work - those at the top of the learning cycle will have a deeper understanding typically.

So how could that possibly obligate tech support to do anything other than support product specific issues?  It does not.  However, things are never so clear-cut.

There are only two answers, really: provide support, or don’t provide support.  Anything in between that basic premise will cut current or future customers from the potential sales of products.

It couldn’t be any simpler than that. The real issue is to decide whether the “company” can afford to deny themselves the potential revenue, customers, and the word of mouth that helps build business if they choose not to support the use of their product(s), or even just the product itself.

At issue is a sort of value-added support mechanism that answers questions down to the point of programming principles.

It seems that one point of view says that “if you don’t know how to do it, don’t ask until you do”, meaning if I don’t understand how to override methods, set properties in code, or build a framework from scratch, I shouldn’t be asking for help in using controls that would provide more satisfactory results until I know the basic ideas and principles that it is structured to.

The popular new car analogy: it falls flat and should not be used to address this issue. Here’s why:  the industry has educated its end users to the point where they no longer need to directly interact with their customer base. They let dealerships and independent professional shops handle customer education, repairs and of course, sales of the product.

Motor vehicles have been around for over a century.  The technology, while is still being revised and refined, at one time constituted a rite of passage when young men growing into adult-hood could build a street rod, tune-up the family car, or just carry out routine maintenance.  Because it was a matter of basic mechanics to work on and even build from parts a vehicle from the ground up, most anyone could do so.

But now, not because these things can’t be done at the end user level, but because design and development of new technologies has moved the home mechanic from his garage, and for the most part, are being forced to seek out services for the new, highly complex machines as they are not able to apply basic mechanics learned in high school shop, or simply lack the money to do so.

The industry itself over-ran the end users ability to manipulate things on their own.

True, you would not ask a car dealer to teach you how to drive. But you would want them to teach you how to drive something that doesn’t conform to current technology.  Consider all-wheel steering used for parking parallel in a tight spot. Someone would definitely need to show me how this is done, given that simple written instructions can’t address the fact that I have no experience with this specific adaption.  And if they wouldn’t, or couldn’t, then I would not be interested in the product regardless of the presumed benefits of its function. The benefits don’t exist if I can’t take advantage of them.

Would they be obligated to do so? No, for the same reasons tech support - in the context of this post -- doesn’t have to do the same. But it would be something of a guarantee another industry would pop-up to do just that, and the engineers, designers and architechs are free to move forward with their latest and greatest.  Isn’t this like turning your back on a valid revenue source?  Seems certainly so.

But imagine how slow to market their product would be if no one except engineers, designers and mechanics understood the depth and breadth of its uses.

A rather elitist attitude sort of presents itself – further putting off the actual end-user – and fulfilling the narcissistic-minded inventors need to succeed without sharing.

Alternatively, I could spend another 4 years in school, intern again somewhere, and then spend the remaining ten years or so of my working career keeping up with techno-evolution.  

Developer Express is having things the way they want.  They control who receives what level of information that is related to their products, and is clearly engaged in educating their end-users, which insures an understanding of their products.  They know it is important to help those with lesser knowledge; it is good business for their bottom line.

That likely will end when there no longer is a need for people like me to learn programming so we can put the current technologies to work in our businesses.

For those that believe the value of such a principle currently is no op, I believe would find themselves locked to a very small group of users, and would lack growth potential.

23 August, 2007
Ian Ringrose

A large part of your marketing is that your controls are the same for Aps.net and Win Forms, your examples on your web site shows then as being the same etc.   Therefore it reasonable to expect that a developer that knows how to use them on WinForms can just use them on Asp.net.

We often get spec that say, put it on the web, but make it the same as the old fat client application.   When we say it is not easy, our MD says it is easy, because your website says it is easy.

29 August, 2007
Mike Stephenson

I understand this must be very frustrating.  But I think the trick is to grin and bear it and do the sorts of things that make it less of a burden, as has been suggested (knowledge base entries, more tutorials, code samples, etc.).

I should mention frustration comes from both sides of the fence.  I've wasted hours and hours of my time working through bugs where I first assume it's something I am not groking when in fact it turns out to be bug in a component that should never have been missed.  This happens all too frequently with component vendors, DevEx included.

So while customers may appear to waste valuable support hours, we are also the people that report bugs to you at no cost to you but at a cost to us.  And it is these bug reports that make your products better and increase your revenue.  Some of these bugs should never make it into a shipping product (like one I recently reported which did not even get looked at until I wrote a sample project to demonstrate it).  Yet we spend our time reporting them.

So yes, we don't know enough sometimes and some of us may ask stupid questions that you should never have to answer, but we are the only source of revenue you have.

31 August, 2007

Please login or register to post comments.