Perception, deception, reception

This past few work days have been up and down. It's a bit like the old joke that starts off with "I have some good news and bad news..." and then gives us the bad news, and then the good, the joke being that the good news is worse than the bad but in a different way.

Well, I'm going to do this the other way round: first the good news and then the bad. By this masterful switch, the good is really, really good, and the bad is simply awful.

First off was a link that Dale Mitchell provided in a comment to my post on CodeRush and Refactor! Pro 2.5. The article is an interview with James Moore of Red Gate Software, a company that is mainly known for its line of SQL-related tools, but that is starting to diversify into .NET tools with their ANTS profiler. I won't comment too much on the content of the article, but will point out the second question and answer as being particularly relevant to us and our industry.

Yes, writing your own controls is fun and instructive and means that you can hone and gear it precisely to your particular situation, but in doing so you are increasing the amount of code you have to maintain, you're increasing the cost of the software you really should be writing, you're not adding to the bottom line. DXperience Enterprise, containing everything that we do for .NET, including all source code for the components, costs $1,300 at present. Say you cost your employer $100 an hour (you know, it'll be close with salary, medical, dental, vacation, 401(k), options, stock, etc, etc). That's 13 hours of your time, less than two days. Are you going to design, write, test, bug-fix a tree-view, for example, in that time?

(By the way, Mark Miller gave me a redacted question 2 answer with certain passages marked in bold. I decided not to use it, though I'll leave it as an exercise for the reader to reconstruct his version.)

Then I saw that Andrew Connell had made the results of his work in writing templates and plug-ins for CodeRush and Refactor! Pro available for all Sharepoint programmers. For free. Zero, nada, zilch. OK, you do have to buy CodeRush for about $250 (Refactor! Pro is included in that price, remember) to use them, but considering the amount of time this is going to save you, it's a mere pittance.

In reading the blog posts ( 1, 2, 3, 4, 5) where he talks about it all, frankly I'm stunned at the amount of work in the project and in the magnanimity of Andrew's gesture. Now, in my defense, I'm not a Sharepoint programmer, but Andrew is and he's distilled his knowledge and experience into these additions to CodeRush and Refactor! Pro that will make your life easier.

First and foremost, let me say this is awesome work, and secondly, and to a lesser extent, it validates the direction Mark and the team took in ensuring that both CodeRush and Refactor! Pro are fully extensible with a well thought out design and great support in the form of project templates and the like.

After that, I read Chris Bilson's blog entry on modifying a CodeRush template to help program with NHibernate. A nice little article on extending what we provide as part of the product to make it better and easier to use for your normal daily work. In Chris' case, it's declaring virtual properties for use with NHibernate, a well-regarded ORM derived from the Java Hibernate framework. He's got the screenshots, he's got the shaky mouse highlights (I'm there with you, Chris), resulting in a very succinct tasty article indeed.

Then after this surfeit of good news, this morning I read this rant about component vendors. I'm certainly not going to dissect who irascian is talking about so vehemently, but instead view it as a rant about all component vendors, of which we are certainly one, and reply on that level. He makes some (qualified) good points and some quite bad ones. I'll look at the ones that could apply to us.

- Support as an endless loop of responding to a question with another. We've been dinged on this one several times (it annoys me incredibly), and have recently been making changes to some of the answers we make in order to try and cut short this go-around.

But, having admitted that sometimes we're to blame, I'd invite you to look at the problem from our viewpoint: sometimes the question that's asked of us is ambiguous to the point of obscurity (I remember seeing one of Plato's answers recently: "Are you talking about the ExpressQuantumGrid, the XtraGrid, the ASPxGrid, or the ASPxGridView?"). After all, we can imagine that it's coming from a customer who's been living this issue of which they're complaining for the past several hours. They're fully intimate with the problem and the scenario and forget in the heat of writing an email to us that we're not. So sometimes, we're forced to respond with a question.

- View Source (for an aspx page containing some third party controls) provides "total gunk, debris and sheer volume of crap". Heh, message received and understood. I'll admit our editor controls are somewhat guilty, and we're looking into the TGDASVOC produced when they're used in the ASPxGridView and hope to show the new slimmer controls in version 2007.3.

But having said that, does the end-user care about TGDASVOC in the HTML? So long as it's rendered by the browser they're using, do they really care that it was 3K of HTML or 4K? The images on the page are going to be larger than that anyway. To me it's a little like arguing that XML should always be nicely indented for human readers. Er, no, it doesn't have to be; human readers fall into second place compared to the program readers, surely?

- "there's no real competition". Do what? The mind boggles. Is he saying that we, Infragistics, ComponentOne, Telerik, etc, are in cahoots? Price-fixing? That we're just four facets of the same shady reclusive shell company in Liechtenstein that doles out the sales? My mind has completely boggled over on this one and I'll have to move on before it comes out my ears.

- Side rant about Community Server 2007. Er, complain to Telligent. We do, and how. Don't assume that they're using a third- party vendor's components. Maybe they are, maybe they're not, maybe they've taken a commercial product and made lots of changes to suit them. Dunno. But they're the front line of support for Community Server.

Now having said all that, let me point out a few things. Compared with writing WinForms controls, writing useful ASP.NET controls is hard. Sorry to be the bearer of bad news, etc, but it is. For a start, they're written as C# (say), HTML, and Javascript. They're stateless, with some decidedly kludgey ways to try and make them stateful (which the component user tends to break quite frequently). HTML was not designed for fancy interactive UI work, although there is work going on in that area to make it so, and so requires all this kludgey Javascript. The browsers are all different (the DOMs aren't the same, neither is the Javascript) and even the script routines that determine what the browser supports make me laugh with amazement. (In fact, it was only ASP.NET 2.0 that made a real effort to determine which browser was what, and that work continues with Silverlight.)

Of course, that's why we're paid the big bucks — partly in order to fund magazines and conferences, it seems — therefore we should spend the time and effort to make sure our super-duper grid works in all the browsers, on all the operating systems, with minimal HTML and JS and Viewstate, with rock-solid state persistence, and blazing performance. Which we do, happily. And in doing so bugs are reported which we fix. And we tweak based on feedback from our customers. And customers can rely on us to do all that, because, as mentioned above, they get a lots of value for two days' worth of work.

I used to work for a company that decided early on that they would write their own grid for their ASP pages (no, this was before ASP.NET). It was geared to their application, it had loads of special case code everywhere, and nobody, but nobody, in the dev team wanted to touch it. Change one thing in one place and functionality changed somewhere else. With the best will and effort in the world, they ended up with a Frankengrid. More time was spent on the underlying infrastructure of the grid than on the application's UI. They're now rewriting with a third-party vendor's product. I'm sure that it's not optimal compared with the old custom one, but the way they look at it, is that they're in the business of selling an application, not a grid.

And that's what I find troubling about irascian's rant. It's easy to lash out at and blame your vendor for slippages and problems (or to lash out at the unnamed person or persons who decided on this choice of vendor), but I certainly believe in the end you will save money by using one. Just spend some quality time investigating which one to use. Use real code written by a real programmer and use real data. A week spent on this investigation will repay dividends.

As we like to say, Download, Compare, and Decide.

Free DevExpress Products - Get Your Copy Today