Call me a grouch, but, since the halls of DevExpress Towers are quiet and people are wrapping up their individual 2008s, I thought I'd unload a little, gentle reader.
I've been replying to a few questions from our info mailbox (email@example.com). It's one of my jobs; a daily task, in fact. In general, the questions are pre-sales in nature and are well-formulated and seeking to gain information not found anywhere else. (Current customers tend to use our support services.) Some require me to do some research in order to find out the True Answer (tm) because even to me, as I approach my third anniversary here, some answers are not obvious. So, I fire up Google, that fount of indexed knowledge, and fire off variants of phrases together with the "site:" keyword to see if I can't get at them. Some use "info" to try and elicit some advance knowledge of our plans and goals for the products to which I can only reply in generalities and fuzzy timelines.
And then there are some, which, to be frank, indicate the sender has spent little to no time in any investigation whatsoever but fires off an email because it's easier.
Yes, we'll take it on the chin that our docs need improving. Yes, we'll agree that sometimes it can be hard to find the answer. Yes, we'll accept that sometimes our design isn't optimal so your intuition fails. We're continually trying to improve everything we do, from design, to implementation, to testing, to writing, to support, to shooting videos. to exhibiting, to whatever. We have to, our market is very competitive, natural selection has a field day.
But, when it comes to the point of me answering one of these info emails, and I don't know the answer, but I find it within, say, a couple of minutes of searching and reading online then there's something wrong that no number of improvements we can implement will ever ameliorate.
However, here's my general plan of attack should I not know the answer to a question involving our products.
- If the question sounds like it should be covered by the documentation, I use the online version and drill down. A bit inefficient, I'll agree, but I find I gain some background knowledge as I do so (especially in reading the overview sections). As an example, the scheduler can be a bit confusing when it's time to talk about persistence, but I find the SchedulerStorage overview very well-written and illuminating.
- If the question is about the end-user behavior of some control, I fire up the DemoCenter application and go take a look. This app is installed by the evaluation version, so is available to "pre-customers", and it's invaluable in determining what a control can (or cannot, for that matter) do. The dev teams spend quite a bit of time here making sure they can show off the features to the product, so if it's not there, it's unlikely we can do it. Of course, if the control in question is for ASP.NET, I hit the online demos.
- If the question is about how to implement something, there are several places to look. First of all, I'll apply the above two strategies. Some newer demos, for example, have an option to display the code for a feature. If I see some code with identifiers that look about right, I'll use these in preference to natural English in Google. Another place to look is our knowledgebase, which of course leads to Code Central (where again I'll tend to browse filtered results instead of brute-force search). Again, if there's an identifier that looks interesting, I'll google for that, coupled with the product name — every now and then you can reach somebody's blog where they discuss something similar. Sometimes I'll even use the source, Luke, or at least Reflector.
It's very rare that I give up and ask the support guys or the development team itself. But, hey, it has happened.
My exposition here is more general than just for DevExpress. I use the same techniques when I'm searching for information on other products. For instance, I use Graffiti CMS as the engine for my personal blog and I've been playing around recently with its extensibility points. To find out how to do something with Graffiti, I apply these very same techniques (but, boy, I wish they'd called it BlogSplat or something, I'm getting tired of reading about urban graffiti issues).
Anyway, if you do have a pre-sales question about our products, please don't hesitate to email firstname.lastname@example.org. It's filtered through our sales team first, and they decide whether they can answer or pass it on. You may therefore get an answer from me, and you can rest assured it will have passed our grouchiness filter .
If you have our product already and have a question about it, then point your mail program at email@example.com. If you have a question about purchasing or about a purchase you have made, write to firstname.lastname@example.org. If you have a deeper question about our strategy, or complaint about someone at DevExpress, or want to donate several million dollars to our retirement fund, email@example.com is for you.
And if you want to email me, I can always be found at firstname.lastname@example.org. I enjoy hearing from everyone.
With that, I and everybody here at Developer Express wish you all a very happy and prosperous New Year. We look forward to helping and being here for you next year.