This Blog


Favorite Posts


December 2006 - Posts

  • Bugs and mailers and apologies

    If you're a VCL customer, we did something bad to you today. We went live with our new client center software, but there was an awful bug in it. To be precise, the bug was in the notification mailer subsystem, which proceeded to mail out the same release notification email to the same people (our VCL customer mailing list), over and over and over and over... Eight times in all. (Well, that's how many I got, you may have been luckier. Or should that be unluckier? Sigh.)

    As soon as I noticed, I told our support team, who already knew about it from the several customers who'd emailed complaints. Of course, the developer of that part of the system wasn't in (gotta love the Holiday season, don't you know), and by the time we'd worked out what to do to shut it off, we'd sent out several — at least eight — notifications to everyone, all exactly the same.

    As soon as we'd stopped the errant mailer, I was in a quandary. Many customers who'd complained were adamant about never hearing from us again, but I wanted to send out an email as quickly as possible to everyone concerned apologizing for our mistake. There was no way we could remove those customers who'd emailed us about the problem from out mailing list in the time. So I decided that we should send out the apology email immediately (using an older, working, version of the mailer program, obviously; I shudder to think what might happen if we used the new one and the VCL customers then got eight copies of the same apology — gaaak), and then I would personally reply to every customer who'd written to complain.

    I've just completed the first stack of personal replies that I have to make and thought I'd take a little break before continuing. The apology email has provided nearly 1800 items in my inbox so far, most of them the usual mail server replies (out of the office, not a valid email, over quota, rejections, etc), but also some real replies which I shall be reading (and replying to, if needed) in due course.

    I'm reporting this here, not to make me out to be some kind of hero or weirdo, but to emphasize how important I feel this issue is for us. We screwed up badly — there's no other way to put it — and it's up to us to make good by admitting it and apologizing as quickly as possible. To that end, I even included my cell phone number in the apology email I sent out so that people could talk to me in person if they wanted to.

    If you are a customer who added devexpress.com to their junk blacklist, you won't have received any of my communications to you, so please accept my and Developer Express' public apologies for what happened today. We're not in the business of spamming anyone, we're here to write great components, frameworks and productivity tools.

    Just don't ask to buy our new Client Center software. We need to test it a bit more...

  • XAF: a jigsaw piece or the whole puzzle?

    Now that we've released the first beta of eXpressApp Framework (XAF), we should explain our thinking about how we're going to position it. After that, I'll briefly talk about pricing.

    First off, we're of the firm belief that XAF will be able to target a different customer base than we've been able to focus on before. Our traditional customers — and if you're reading this, I'm going to guess that you're one of them — are expert developers who know how to get the best from the components we sell. We sell our components as "pieces, parts" and rely on the ability of our customers to configure them, resize/dock them, link them up, and extend them with code to produce awesome applications with a great UI. That kind of demographic will be interested in XAF, certainly, but not to the same extent as someone else who's not so comfortable with this "Lego- like" methodology.

    And that's the kind of customer we see as being of primary importance for XAF. The customer who doesn't want to drop components on a form and link them up and write glue code. The customer who wants a pre- configured, works-out-of-the-box application generator, even though to the purist it may seem too restricted or limited. The customer who doesn't have time for tweaking the flexibility knobs and dials we're known for. The customer who doesn't want to pay a contractor to create a small application but also doesn't have the resources/time to do so himself using our traditional offerings.

    That's not to say that someone from our traditional customer base is not also one of this type of customer as well. There will be some overlap. However, I can imagine that the majority of our current customers will see XAF as being some kind of "cute toy" and never use it because of its perceived limitations, real or not. It may even be that, when part of DXperience, XAF just won't get the exposure that it needs, that it just gets hidden amongst all the other great stuff in there.

    Then there's also the issue of releases. Although we could force XAF to have the same major release schedule as DXperience, we've already found that it doesn't mesh well with that timetable. XAF features tend to require more "architecture", be harder to implement, and require more time to bring to market. Constraining ourselves to the quicker release schedule of DXperience will produce XAF features that are not as well thought-out, that have more subtle issues, than we would like.

    So, all in all, we've decided that XAF shouldn't be part of DXperience Enterprise, but should be a separate product altogether. Those customers who need the flexibility of writing their own applications with all the knobs and dials at hand will choose DXperience; those who want to generate business applications quickly but aren't too worried about the "sameness" of them all, XAF. You don't need DXperience to use XAF, since it comes with all the controls it needs in several run- time assemblies, and certainly you don't need XAF to use DXperience.

    Now, let's talk about pricing. So far we've given away the CTPs and the beta to XAF, but, pretty soon we're going to have to charge for it. Therein lies a problem: I just don't know what the pricing plan is going to be. We are still discussing it internally (and the release this morning prompted yet another chat about it), but it seems likely that we would have some kind of promotion whereby you can get a discount on XAF if you own DXperience and vice versa. However, I have no idea what those discounts might be, nor am I aware of the final cost for XAF on its own. As soon as we have more details about pricing, I'll let you know.

    UPDATE (same day, couple of hours later): Actually the first commenter reveals he knows more about this than I do, so I'd better stick to technical things in the future :-). XAF without source will cost $799.99; with source, $1499.99. This is the first year subscription price, with further renewals being at 40% of the first year's cost. If you own DXperience Enterprise between now and the time of XAF's release you will get a free year's subscription to XAF (to satisfy some promises we made very early on). Still no news about discounted promotions though (I'm on safer ground there...).

  • And the survey says...

    Recently we sent out an email blast to all the customers of our .NET components asking a simple question: are you in agreement that we should concentrate our future development for .NET 2.0 or later? The email followed on from this post I'd made and was intended to get some responses that may have been more frank than public comments to a blog post. I would like to take this opportunity to reveal the results of that informal survey.

    It will probably come as no surprise to you that the majority of respondents (85%) unequivocally agreed with this strategy.

    Having said that, I don't mean to imply that the remaining 15% of respondents were dead against it and were ready to storm DevExpress Towers with pitchforks and burning torches. By no means, thankfully. Unfortunately, I don't think we were clear enough in the email (and possibly neither with the blog post as well), and a large number of the 15% were just worried that we were going to abandon them to the legacy code sharks, even though they were planning to move to .NET 2.0 in the next year anyway. So let me be unambiguous, and in bold to boot:

    Developer Express will continue to support and maintain its components, frameworks and tools that target .NET Framework 1.0 and 1.1.

    So we will be providing bug fixes and minor enhancements for the foreseeable future for version 2006.3 of DXperience. By that I mean all our products that were revised for that version, and also the upcoming version 2.1 of our IDE productivity tools, CodeRush and Refactor! Pro. If you are using some component or tool from these latest versions with .NET 1.x, rest assured that you'll continue to get support, bug fixes and workarounds for them as long as it makes sense.

    Version 2007.1 of DXperience will be our first release that targets just .NET 2.0 or later. All our new development, new components, major enhancements, and new functionality from this point on will be for version 2.0 of the .NET framework, and indeed some of our current products are already .NET 2.0 only. The story with regard to CodeRush and Refactor! Pro is a little more fuzzy mainly because of DXCore (it's shared between all versions of Visual Studio you have on your machine), but be warned that the next major version will most likely just be for Visual Studio 2005 or later.

  • eXpressApp Framework beta 1 is released

    Earlier this morning we finally released our first beta for eXpressApp Framework (XAF to the cognoscenti).

    This product's premise is an extremely interesting one for me: a .NET 2.0 framework that can create business applications either as rich client apps (WinForms) or as browser apps (ASP.NET 2.0). Or both. The architecture used by XAF is a variant of something I used to promote (sometimes vainly, sigh) in my previous roles as architect before Developer Express: the separation of the business object layer from the data access layer.

    The XAF team have done a remarkable job: not only have they enforced separation between the business and the data layers, they've also done the same for the presentation layer as well. Hence, although XAF targets WinForms or ASP.NET at present, the architecture is so designed that a move to other presentation layers like WPF will be fairly easy (in fact, the main problem at present with a WPF target is the lack of rich controls -- something else we're working on).

    XAF is built upon our eXpress Persistent Objects (XPO) framework and exercises that underlying framework thoroughly. You can declare additional business objects (or enhance current objects) easily in code and the schema analysis tool in XPO will update the database schema the next time the application is run. Even now, after knowing about this facility for a while, I find it a great acheivement: it's nothing less than agile database development.

    Anyway, go here to read about the scope of this first beta, or here to read about the architecture and the underlying models and layers used by XAF. The XAF Beta 1 can be downloaded from here.

  • Right-to-left language support

    (Note: comments are now disabled for this post.)

    This week was shaping up to be somewhat unusual, and then suddenly I've become involved in discussions with several customers about right-to-left support.

    Let me provide some background. Our components for VCL and .NET do not currently support right-to-left languages like Arabic or Hebrew. It's not for want of requests: we do get a steady but quite small number of requests every month for this kind of support. However, for some unknown reason, this week I've been discussing our right-to-left (RTL) support with several customers, or more accurately, our lack of support for RTL languages.

    It's not that we don't know what to do to support RTL languges. We even have a pretty good idea about how long it would take. No, it's not the knowledge of what to do that is the problem, it's our resources and how best to deploy them for the benefit of the majority of our customers.

    Although we have a regular, but small, rate of requests for RTL support in our components, it is dwarfed by the number of requests we get for other functionality and enhancements. When we make decisions about what we should do in future versions of our subscriptions we have to take this groundswell of opinion into account.

    In short, because we have limited development resources for enhancing our components, we must deploy them in such a way to maximize our revenues from their work. This is a pure business decision for us. And that, unfortunately, means RTL support is just not high priority -- the majority of our customers would prefer we enhance our components in other areas and directions.

    Now, it could be argued that we would get new customers if we had RTL support. I don't doubt it in the least (and the Middle East, where the majority of RTL languages are used, does have a large proprtion of the world's population, hence presumably a need for RTL UI controls), but given the small interest we've seen, I don't think we'd recoup our investment very quickly compared with other strategies for developing our product line.

    However, we do sell our products worldwide. So, let me ask you... Are you ignoring our components because we don't have RTL support? Are you going to be marketing your products to the Middle East soon, in which case you'll be needing RTL support sooner? Would you ignore RTL support because your main markets use Latin or Cyrillic alphabets? Any other comments?

  • Delphi and VCL developers: see our ribbon in action

    Just a very quick post for our Delphi customers. You can download a demo program of our new VCL ribbon in action. I warn you that the demo is written with beta code and, although it shouldn't crash (at least not too hard :-) ), you may find some functionality missing. We'll be updating it periodically as we add new features and fix bugs. Enjoy!

    VCL Ribbon demo

    The release date is mumblety-mumble. Mmm, there seems to be an automatic release date censor in this blog software...

  • "That (expletive) support!"

    Every now and then, I get to talk to a customer about support, specifically an issue for which they've had to use our support facilities. For multiple reasons, sometimes those interactions are not as good as the customer or the support team or I would like, and I get in contact with the customer to investigate to see whether we can learn anything and become better at our support. I had occasion recently to write a longish email to one of our customers about how we do support and, specifically, how we'll sometimes ask for a sample program that reproduces the customer's problem. I thought I'd generalize it a little and post it here.

    (A quick note: in this post I'm not going to talk about what we're discussing with regard to increasing our support options, such as the possibility of paid, premium, or phone support — the three Ps of tech support — because we're nowhere near ready to make any announcement about whether we are or are not going to do anything about it. So please don't ask :-).)

    Although some of the issues that are reported to the support team are of the "duh, that's obvious, why didn't we catch it?" variety (necessitating some soul-searching about the depth of our testing, with me tapping my foot and glaring :-) ), a lot quite simply are not. For the latter type, sometimes we have published workarounds in our knowledgebase, but it seems fairly apparent that the issues could be due to one or more of the following:

    • The customer's environment. This could be the operating system, the video driver, the IDE, etc. What's special about it versus the systems we use for development or testing?
    • Bad interaction with other controls on the form. These could be our own controls — maybe we didn't test a particular combination — or other vendors' controls — in which case, we'll do our best to investigate. (The most funny, in a peculiar rather than ha-ha sense, was the recent report that our grid wasn't working with this free control that the customer had downloaded. It turned out that the control was a pirated rip-off of one of our other controls and had a bug we'd already fixed.)
    • Some workflow with our controls that we didn't envisage. Although we try to predict how our customers will use our controls, and our help and demo programs show how we expect (hope?) the controls to be used, our controls' very flexibility and customizability means that we can never really be sure that we've tried every possible combination. Actually I think we should employ some of our customers as testers: they have a great propensity to do things like switch database connections in a display event handler. (Only joking!)
    • The database engine. Perhaps the customer is using a database engine we don't regularly test with or have never used. In this case we can approach the database engine vendor to get a test copy -- we have done this many times in the past and are doing it right now with a couple of vendors (our XPO product tends to, er, exercise database engines quite thoroughly, shall we say). This actually works both ways: some database vendors ask us for a copy of such-and-such a control because they have a customer with a problem ("it works with SQL Server, but not with your database") and they want to solve it.

    Some of these scenarios we can certainly investigate when we get a bug report (which is why we ask for a lot of ancillary information as part of the report), but for some of them we simply have no other alternative but to ask the customer to help us isolate the issue. That's when we'll ask for a sample test program with code (and a sample database, if needed) that shows the problem. In rare cases, we'll even ask, if that initial request doesn't expose the issue and if the customer is willing, for the customer's actual project.

    We certainly don't do any of this to annoy or brush off the customer ("heh, he'll never do it, so we can close the issue, gimme five!"), we ask because we want to find and fix the problem. Sometimes the simplest way to find a bug is just to trace through the code in a debugger. We have found, through many such requests, that this approach helps both our support people and the customer to resolve the issue most of the time and definitely as quickly as possible.

    Sometimes, even the very act of writing a simple application to show up a bug reveals the problem immediately, and it becomes a "duh, that's obvious, why didn't we catch it" bug (cue more foot-tapping and glaring). Many times a sample project enables us to provide a workaround or make some suggestions for the customer as we schedule the bug to be fixed or the knowledgebase to be updated. Sometimes a sample project enables us to regretfully say that our product simply can't do what the customer wants, the famous "it's working as designed" resolution.

    I must say that I'm proud of our support and proud of the support team. I feel that our support is a differentiator for our company. I'd have to say from my viewpoint the majority of support issues are handled well, with the customer able to continue working with our products at the end of the day, but as I said earlier, sometimes they're not and I get involved.

    So please don't get upset if we ask you to help us fix the issue you found by providing a sample program. Principally, we're doing it to help you but, ultimately, doing so helps all our customers by enabling us to provide better products.


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners