This Blog


Favorite Posts


April 2009 - Posts

  • System Requirements: when the plural of anecdote really is data

    I had an interesting email assigned to me today, one that posed a question I hadn't come across before.

    This requires some explanation, not the bit where I hadn't heard the question before, but the reference to assignment of emails. We not only have our own email addresses at DevExpress (mine is julianb@devexpress.com, in case you'd forgotten), but we have generic email addresses too:

    What is not known is that messages to the first two are diverted into a big email database, mainly because people sometimes send sales emails to info, and presales emails to clientservices. We don't want to act all snotty, "Hey, send your purchase email to clientservices, we at info are all about presales questions," because quite honestly we'd be beaten about the head by everyone. So Azret has written an awesome WinForms ClickOnce email application (affectionately known as DXMail) — using our controls, of course — and someone goes through the pool of unanswered emails and assigns them to individual people, generally the person best able to answer the question. This email application is in the process of being merged with our support center application too, so that support questions that come to one of these two email addresses will get routed properly. (I'd show you an image of the app, but it would be full of fuzzed-out private information.)

    Anyway, I got assigned this particular email, a presales question, and the author wanted to know the minimum system requirements for a WinForms application written with our controls, or, failing that, at least the recommended requirements, especially with regard to RAM. Yep, a perfectly valid question and the old CTO was stumped: we don't have any data on this. Obviously for the OS and hardware requirements I can just point to whatever .NET requires, but what about RAM size?

    So I went to MSDN to find out the system requirements for .NET. For version 3.5, the minimum RAM requirements are, wait for it, 96MB. Good grief. The recommended amount is 256MB. Yeah, right. I have absolutely no idea how that number was arrived at. Did they write an exemplar application with .NET and then run it on these RAM-limited machines? Don't know, but at least I have the official recommended amount of RAM to run a .NET application.

    But what about our stuff? How much would that add to the equation? OK, now I need a reference application that uses our controls. Bingo, DXMail. Now I need a limited machine. The one I came up with was my Dell Mini 9 netbook, with its cavernous 1GB of RAM (an eighth of its drive space, I'll have you know — you don't exactly want to hibernate this baby). Handily, DXMail is ClickOnce so I could easily install it (like all small netbooks, there's no DVD drive to install from). So I logged onto our servers through VPN and started the download to install it. After that, I ran the app, and it came up and emails were shown and I could reply to them, etc, etc. Gobsmacked, I was.

    But what had I really shown? (Apart from the ability to do another chunk of my work on a very small screen in Starbucks, that is.) Sure, DXMail runs on a 1GB machine, but is that a recommendation? Can I derive any data from this single anecdote? For it comes to me that all I've proven is that this one .NET application whose data is at the end of a broadband pipe works on my netbook. What if the data were all on the machine itself? What if the grid is being used and server mode is off so all data is downloaded to the grid for display? DXMail "ships" with skins, but would their exclusion make any difference? And so on.

    In the end, the only conclusion I could come up with was the requirements for our controls can only be understood in reference to the application written to use those controls. Even further, the RAM requirements would depend on what the end-user would be prepared to suffer performance-wise. Yeah, I'm sure DXMail would work in 256MB of RAM by swapping the heck out of stuff, but would I be prepared to use it under those circumstances? (Another anecdote: Task Manager reports that DXMail is using 40MB of memory, so maybe 256MB would indeed be fine.)

    I also considered whether we could derive any data ourselves rather than rely on the anecdotal information from yours truly, say by writing a reference application and running it as part of our testing. But again I'm led to the conclusion that any data we'd get would be trivial at best or too vague at worst: "We recommend at least 512MB of RAM to run a well-written WinForms application using the majority of our controls." Notice all the wishy-washy caveats and those hedging terms. I really don't think we'd get anything better than that without getting bogged down in definitions of "run" and "well-written" and "majority". So in this case, I think anecdotes are about as good a set of data as we can manage.

    Oh, and we recommend at least 512MB of RAM to run a well-written WinForms application using the majority of our controls. Smile

  • Business during a recession

    Last week I got the latest issue of The New Yorker and, as usual, whenever there's an article by James Surowiecki, I turned to it and read it first. Surowiecki writes well and intelligently on financial and business matters, and this week's article was no exception.

    His thesis this time was how businesses behave during a recession and used Kellogg and Post as examples during the Depression during the 30s. In the 20s, both were equally well known for breakfast cereals, but when 1929 hit, Post reined in its expenses to ride out the storm whereas Kellogg increased ad spending and launched Rice Krispies. The result: hardly anyone knows of Post these days whereas Kellogg's is a household name. Even more importantly, perhaps, Kellogg's profits were increasing even during the Depression.

    I got to thinking about our industry, especially in these turbulent economic times. The immediate thought is to reduce expenses, especially when it's probable that revenues will decrease too. Ride out the storm, in other words; don't rock the boat. But that's the risk-averse strategy and low risk generally means low rewards. A higher risk strategy could mean much higher rewards, but the downside could be more too. But if everyone else is being risk-averse, there's more of an opportunity to make big if you don't follow the crowd: don't miss the boat.

    For us software companies, there's a similar decision to be made in bad economic times. Do you just cut back on ads and conferences and giveaways, and just invest your money in R&D? When the bad times are over (although it can be really difficult to spot this kind of trend at the time), you can revamp your marketing and you'll have a new product to boot. Certainly with tech companies there's more of an opportunity to do "cheap" marketing through social software, but in reality your reach is not that great: it's hard to find new customers through Twitter for example. And, of course, once you determine that the bad times are over, you want to reach new customers immediately. You don't want to spend the time ramping up because, after all, everybody's trying to ramp up at the same time and how do you differentiate yourself? Better to keep yourselves in front, in the face of your current and possible customers throughout.

    The same thing goes for competition in a recession. If you are competing against the free and the open source, what do you do? You can either do nothing, or knuckle down and write a competing product that you hope people will stump up money for once it's done, or you become visible right away in your particular open source space and provide help and work out along with the community what the free product lacks. The risk here is that, no matter how you do, you're always going to be too late with too small a product, and will waste resources and time and money. However, if you succeed, because of your visibility and because you've honed your product through your interactions with the community, you'll make out like gangbusters.

    In fact, you don't even have to go that far: release a full-featured, but light version of a product for free, and then provide the more in-depth features to solve the advanced scenarios as a paid upgrade. The risk here is that the features you provide with the free version are enough for the vast majority of your customers.

    My point here is not that software companies should or should not take risks, but that they should not radically change their outlook just because the rest of the world is in a recession. Software development is not car manufacturing or ship building or any other kind of production of physical goods. Indeed, I'd venture to say that software companies as a whole will continue to do pretty well in a recession because the market for software doesn't really "go away". Indeed I'd argue that other companies will invest more in their software infrastructure during a recession in order to come out of the gate as fast as they can. Sure, they'll be more parsimonious deciding what they need, or critical of what the various software vendors are supplying, or desirous of value for money, but in the end I'd say they will purchase. Take advantage of the recession by targeting your customers and your market!

    Oh, and we'll see you at Tech·Ed in a couple of weeks' time: we're in the Exhibit Hall between Intel and HP ;). I wonder how they'll cope.

  • Put your (medium) trust in XtraReports, the premier ASP.NET reporting tool

    Not a lot of people know this, it seems (it came up again in a pre-sales phone call), but XtraReports can create reports for ASP.NET that will work on web hosts that require medium trust rather than having to force the hosting service to grant full trust.

    I'll let that sink in for a while.

    Yes, indeed, those reports you've created in the past that could only run in full trust (with all the attendant security issues) can all be converted to XtraReports and run on a medium trust server. I thought it was an important enough topic to blog about it here so that everyone knows.

    However, there are a few limitations to running reports in medium trust, even from those awfully nice people at DevExpress. We are working on reducing these as much as we can. First of all, here's the definitive article from MSDN that explains all about medium trust in ASP.NET 2.0. The current limitations are:

    • Running end-user scripts, or loading a report from a REPX file or a stylesheet from a REPSS field is not allowed under medium trust, since they all involve compiling code in some sense and that's not allowed.
    • Creating 3D Charts is also not allowed since we use the OpenGL rendering library, another no-no.
    • Exporting to a metafile or rendering an XRChart control as a metafile (its XRChart.ImageType property must be set to ChartImageType.Bitmap)
    • Exporting to a PDF when you have to embed fonts. Only characters from 32 to 255 are allowed in medium trust.
    • XRRichText and XRPivotGrid controls aren't supported.

    As you can see, providing you avoid some high-end features, XtraReports will suit your medium trust environment down to the ground. Give your hosting company a break and use XtraReports for your web application's reporting needs.

  • Thoughts on netbook trends

    This morning I had an enjoyable interview with a reporter from SD Times about trends in our market specifically (what DevExpress is concentrating on this year) and on our industry in particular (what you might call consumer computing).

    One of the trends I (and many others) have seen over the past 6 months or so is the meteoric rise of netbooks, those small cheap underpowered mini-laptops with 9, 10 inch screens and ridiculously long battery times. The current netbook phenomenon can be traced to the Asus Eee PC in 2007, although certainly PCs like the One Laptop Per Child project has had some influence. Although early netbooks exclusively used some form of Linux with a user-friendly interface, by mid-2008 netbooks were appearing with Windows XP as the OS. Netbooks are also important for their use of SSDs (Solid State Drives) before these became more widespread in normal laptops. Netbooks sales have grown exponentially (an estimated 400,000 in 2007, 11.8 million in 2008, and a projected 35 million in 2009) compared to a stagnant PC market, so much so that it has reduced Microsoft's (Windows XP is much cheaper for OEMs than Windows Vista, and they've been selling boatloads of XPs on netbooks and not many Vistas in comparison) and Intel's revenues (the Atom processor is much cheaper than your run-of-the-mull Core 2 Duo).

    The interesting thing about netbooks derives from their name (part Internet and part Notebook): they're designed for use on the web. Sure the Windows-equipped versions can run normal Windows apps, but it seems that's not particularly what people get them for. For a start, they tend to have small amounts of storage (especially those with SSDs) and no optical drives, so installing software is a bit hit and miss and not many people bother. No, it's all about getting on the web through wifi (although many netbooks now come with 3G cards too) and surfing and using web-based applications.

    In essence, netbooks are more about the personal and not the business life. Since they get online really easily, they target the person who wants to carry around a light small laptop that's easier to use than a smart phone for web stuff. Facebook, Twitter, MySpace and other social sites. Surfing. Reading the news. Watching YouTube videos. That sort of thing. They're about online leisure activities, not work.

    It's amazing how many people are eschewing ordinary laptops to go for a "simpler" appliance-type computing device. A device that only acts as a conduit to applications and computing on the web, that's updated through the web, and that requires the web in order to be productive. To meet that demand, just look at the cloud applications out there for you:  internet mail, Google docs, online backups (although for a device that you don't install anything on, I'm not sure how important those are), and so on. If you wanted to at least install some basic applications like Skype, you'd have a much broader communication experience as well.

    In other words, the fastest rising segment of consumer computing is focused on the web. It's pointing to the growing use of cloud computing, to the rise of social websites. What does that mean for us, you and me, developers writing applications? Well, simple really: the web is where it's at. Sure, there will always be a market for thick clients (probably), but more and more consumers are voting with their hardware money for web access, for the wider interactivity that's affordable through being online.

    Over Easter I bought a Dell Mini 9 (it should arrive this week) and I'm going to be seeing how well I can adjust to a web-only life as a man-in-the-street consumer. Of course, there's going to be developer activities that won't translate, but for the rest I'm going to try it out.

  • Support by Twitter

    Something happened this afternoon that, although unremarkable on its face, wouldn't have worked without a couple of new technologies.

    Missing the dartboard I was monitoring my Twitter stream when I saw that one of our customers was having a problem with the new code issues feature in CodeRush. He'd posted a short tweet (aren't all tweets short?) about all code issues turning into "Complex member (no fixes available)". Sounded weird so I twittered back asking for more details. Unfortunately, at the time, Twitter was going through one of its "slowdowns" — not quite a Fail Whale but close — and so minutes were ticking by.

    Although Mark was online, he wasn't physically present, so I asked the customer to record a video of the problem (our IDE productivity tools are designed to reset a invalid mode on a build, for example, so it's imperative to get a look at the problem before anything like that occurs). He didn't have Camtasia, but Rory Becker stepped in, also on Twitter, with the hint that Jing (also by those terribly nice people at TechSmith) is free.

    While the customer was recording, I asked him for an IM account that we could talk over. Twitter is just not real-time enough for a series of back and forths that a support session would entail. You're throttled to only 100 updates an hour, plus as I said Twitter was being really slow. We switched to Live Messenger; meanwhile he'd emailed me the screencast and Mark was back. We started up a conference IM and I essentially left them to it.

    Very quickly Mark was able to see the problem and understand the reason behind it. In essence, it was a user experience (UX) problem where the "complex member" issue was being prioritized over the other issues. A quick workaround later, and the customer was able to continue with his work.

    Now, before you jump all over this and say: this is how support should work, let me point out a couple of things that meant this particular case was successful.

    1. I was lucky to see the original tweet. I happened to be following this customer for a start, but I don't read everything from everyone I follow (I have real work to do, you know). I don't have a search for 'DevExpress' or 'CodeRush' active all the time, so I could quite easily have missed this particular tweet.

    2. I was lucky to spot the tweet within a couple of minutes. That meant the customer didn't do something like rebuilding, or exiting/restarting Visual Studio and losing the 'mode' he was in, before I jumped in and started asking questions. That's lucky as I say: I usually go for an hour or more before I take a look; it depends on the workload.

    3. I'll say it again: Twitter is unreliable for important things. The fact that you had granola for breakfast is unimportant and I could easily miss that tweet without it affecting your (or my) life in the slightest, but a request for support is somewhat more significant for you. You want a reply, dammit, so there had better be someone watching the stream. (Oh, and I prefer muesli so would have ignored your granola tweet, doubled.)

    4. I was lucky that Mark was online and ready to help. In other words, I had the world's greatest CodeRush Subject Matter Expert (SME) already at my beck and call. (Well, OK, he happened to be online but ignoring me.) The thing about DevExpress SMEs is that they're usually hard at work designing and implementing the Subject Matter at which they're Expert. They are not support guys. Disturb them, and we lose efficiency. You all know what it's like when you're deep in some programming problem and your manager pops his head round the door and asks "how's it going?" Your concentration is blown and it takes time to get it back. Same for our guys.

    5. The customer was willing to take the time and trouble to record a screencast. Not only that, he was willing to take the time and trouble to download the recording software so he could do so. Now, the thing is — I'm going to tread carefully here — a lot of times, customers take the position that their original support ticket description should be good enough to find the source of an issue and then take umbrage when the support person asks for more details, say by including an example program that reproduces the problem or even providing a screencast showing the issue in action. And here we had a customer who was willing to go the extra mile to help us help him.

    (I cannot stress this enough, by the way. Yes, I know bugs suck. Yes, I know your time is disrupted when you come across something that doesn't work the way it should. We feel the same way. So help us help you by giving us all the information you can about the issue you run into. Example programs take time to create, sure, but damn if they're not the best thing since sliced bread at nailing what the bug is and how to resolve it and get you the workaround or fix quickly so you're on your way again. I read somewhere that you should treat tech support as if they were a bunch of six-year olds. Not pejoratively, but in the sense that you should explain every little thing in detail so they understand. Don't make assumptions that they'll comprehend through some sort of osmosis or by reading the subtext in your message: they haven't been living and breathing your code like you have.)

    6. The issue (and the reason for the issue) was visible in the screencast and Mark was quickly able to write some code that mimicked the problem and thereby work out the workaround. This is an SME win, in a way: I'd looked at the screencast, saw the issue, but had not a clue about what could have produced the problem. Mark had the intuition to grok the kind of code that could produce it, and verified his assumption with an experiment.

    As I say, it was a confluence of lucky coincidences that gave the good result in this case. I can quite imagine that in other scenarios it wouldn't have worked out as easily.

    Note that there was no logging of the support — when you use the Support Center or email, each item is logged, queued, and handed over to the correct person and you have a guarantee that your issue will get looked at and you'll be notified of its resolution. When you use the Twittered Julian and non-Twittered Mark, you have no such guarantee. We're unreliable but support is not.

    Another point to make is that support in this manner is very inefficient and costly for us and for everyone else who is waiting in line. It's great for the person being looked after right this very moment, but for everyone else, meh. You know what it's like to be caught in a phone queue: "all our agents are busy right now, please hold and listen to this tune from an 80s band you've never heard of". Of course, this points to the idea of providing premium support and all I can say about that is that we're not there yet.

    So, all in all, an interesting and fairly rewarding experience. but not something we'll make a habit of.

  • Day One reviews of CodeRush v2009.1 - IDE Productivity on the rise

    For fun, I quickly gathered some tweet-reviews of the first day of CodeRush 9.1:

    GaryLCoxJr: It's official, I'm a useless programmer without CodeRush and RefactorPro! from @devexpress, damn space bar does nothing for me without it!

    PaulLiebrand: @DevExpress I am having a good experience with the new #CodeRush update! Thank you for the update.

    cneller: The new #devexpress #coderush installer just rocked my face off - awesome work guys!

    rarous: Nový CodeRush a Refactor! Pro vypadá velice dobře, dnes jště projde zkoškou ohněm :)

    RickStrahl: New CodeRush and Refactor installed. Lots of changes. Install was much imprved and seems VS startup is much faster now (was it that bad?)

    remyvd: Deinstalling Resharper 4.5 beta and installing new version of CodeRush\Refactor

    RoryBecker: ZOMG CodeRush 9.1 HTML templates and Navigation are brilliant -> http://is.gd/qfGk (expand) - read this and weep.... With Joy :)

    sethrowe: woot!! Just noticed the suggestions I made to the CodeRush crew are in the 9.1 build! Thanks @DevExpress

    andrewconnell: Loving the new #coderush & refactor release (v9.1.2), much faster...

    MihaMarkic: Watch out of redundant namespace declarations with CodeRush 9.1! http://twitpic.com/2prf3

    RoryBecker: I feel like kid in a candy store with all this new CodeRush and RefactorPro functionality :D

    craignicol: New CodeRush/Refactor Pro! looks very cool. Wish I wasn't workng on SQL code at the moment so I could try it properly.

    mstortz: Glomming new CodeRush features... mmmm

    ByteMaster: The UX of the static code analysis w/ CodeRush 9.1 has the potential to be as big of a paradigm shifter as the 2x4 ;-)

    ByteMaster: Man it's just like Christmas, CodeRush 9.1 dims unused variables to a light gray...you must install this version, I'm not kidding

    robertlinton: #DevExpress CodeRush & Refactor Pro startup time is noticeably faster, much faster.

    Remember, Mark blogged about the new features here.

    (Remember: don’t forget to vote for your favorite DevExpress tool or component.)

  • Using Twitter on Day One

    Unless you're lucky and have a real life, you'll know by now that we released v2009 vol 1 in the last 24 hours. Twice.

    Twitter bird I won't go into the details of why we took down 9.1.1 after only a couple of hours and then released 9.1.2 after a couple more (needless to say my car is going to be detailed using a toothbrush every week for the next few months), but instead reflect on the use of Twitter during this time.

    Yesterday afternoon, my time (Mountain), we evangelists were twittering in real time about the preparations for the release. @RoryBecker created a hash tag, #AreWeThereYet, so that we could easily aggregate the news about the release. Slowly the level of excitement grew until I announced that it was ready. Almost immediately, people started downloading.

    Once the showstopper bug was found, the install was pulled, and Twitter came into its own again. I was awakened this morning by a DM from a customer (I've set it up so that DMs auto-send a text to my cell phone, and it was on the nightstand). @garyshort and @olivers were already twittering, reassuring everyone who was asking that a new install would soon be ready. I joined in (@jmbucknall) and soon enough the new install was uploaded.

    The point here is that, providing you were following any one of us (or @devexpress) on Twitter, you would have learned immediately that the new install was ready and could be downloaded. To me, this new way of learning about what's happening in real time is exciting. It's not like posting messages to the forums or publishing posts here: it's much more immediate. You're not left in the dark ("What the heck are DevExpress doing?"), but instead can see through our tweets that we're working hard on fulfilling our side of the bargain. It's two-way communication between you and us.

    Incredibly, also, the level of discourse stayed high and people were cracking jokes (the #AreWeThereYet tag grew from a joke I made that customers waiting for the install were like the kids in the back seat: "dad, are we there yet?"). I think that if customers couldn't see what was going on and not getting reassurances in real time from real people, there would have been a great deal more frustration shown than there was. (And, believe me, I can see why people would be frustrated. I can only add "Me too!")

    So, if you're not already a Twitter user, try it out. To encourage you to follow us, we're giving away gift cards and other swag periodically, so see you online!

    (While I'm at it: don’t forget to vote for your favorite DevExpress tool or component.)


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