Why does the devil have all the good tunes?

Creating complex applications in Visual Basic marks the start of a love-hate relationship
Written by David Berlind, Inactive
It's the underlying, built-in, programmable DNA to the word processor, spreadsheet, email client and database that live on just about every desktop in the world. It's the go-to language for nearly anyone -- - amateur or pro -- - who needs to whip out a quick Windows application. Between the endless supply of modifiable example source code free for the taking off the Web, its somewhat intuitive graphical user interface, and a seemingly inexhaustible supply of purchasable add-ons, it's by far the easiest language for new programmers to get up and running with. It's even the stuff that startups are made of. It's VB -- Visual Basic.

If you could possibly single out one culprit as the source of all the incompatibilities that ail our industry, it just might be Visual Basic. Though not in the same league as C++ or Java, it is the one development language that almost no amateur or professional programmer has done without. Over the last decade, the language has evolved to a point where there's almost nothing you can't do with it. Almost. And that's the problem.

Because it can just as easily be used to write software for Windows as it can to automate Microsoft Office, Visual Basic is like a giant vacuum. It sucks you in. With its unique blend of approachability and access to all that Windows and Office have to offer, it's often a matter of minutes or hours before a quick hack can yield significant results.

The problem is that you don't have to write too many lines of code to forever lock yourself into what some call Microsoft's "walled garden." This isn't necessarily a bad thing. Virtually anything you can do with any other "system" can be accomplished from inside the walls of Windows and Microsoft Office. But trouble begins the moment a flower outside the garden attracts your fancy.

My own saga started when I realised that I was repeating the same tasks over and over in Outlook. It wasn't long before I created a macro to speed things up. In Outlook, macros are created in Visual Basic. A year later, what started as a basic VB macro has blossomed into a full-blown application. Realising that the forms that I created along the way were being populated with valuable data that was being tossed away at the end of each macro execution, I got Microsoft's Access database involved. Now, with every email that arrives in my inbox, I automatically generate a friendly, half-canned response, and all the contact data as well the email itself is stored in Microsoft Access. Already, I've found some code on the Web that shows me how I can synchronise the data in Microsoft Access with the address book in Outlook. That's on my list, but there's a host of other improvements that I'm going to make first in the name of even better productivity. After all, productivity is the battle cry for automation.

To say I'm hooked is an understatement. Why?

At one point, my inbox had surpassed a whopping 1,200 emails from readers, vendors, and public relations personnel, all of which deserved a friendly response. The corporate IT department was generating an automated threat that complained about the amount of storage I was consuming and threatened to cut me off. Within three weeks of polishing my code and putting it into production, I'm under 500 emails. My database has more than 1,000 records (that's an average of 333 new records per week). More importantly, the people who have taken the time to write to me are happier. Instead of feeling as though their emails have disappeared into an abyss, they're getting fairly personable replies.

This is my own version of CRM: Constituent Relationship Management. Now that I'm using it, I can't do without my application. Thanks to ODBC, I could probably do without Access, but there's no way I could do without Outlook. Unfortunately, however, this is exactly the same way I feel about the BlackBerry. With BlackBerry's unmatched prowess for managing corporate email remotely and wirelessly, no handheld device has made me not want to leave home without it like the BlackBerry has. But now that I want every incoming email (except for the spam) to be processed by my personal CRM system, the BlackBerry presents a problem because, in the same way that VB is the programming language behind Microsoft Office, Java is the programming language behind the BlackBerry. In the context of the BlackBerry, the work I've done in VB is useless. The BlackBerry is turning out to be that pretty flower outside the walled garden. Not only can't I intercept emails with VB, it doesn't have an Access database and Java is, well Java

Before developing my CRM system, I was able to do the same things -- read, delete, forward, or send email -- on both my desktop and my handheld. That was good for productivity. But now, as the result of my code, the two platforms are no longer on par. The increased utility of my desktop is now somewhat counterbalanced by the decreased utility of my handheld. I need to get the two on par again.

The choices are many, painful, and for the most part, leaving me with the sensation that when I entered Microsoft's walled garden, the door behind me was closed and forever sealed. As I consider my options, I realise the database presents the first challenge. Supposing for a moment that I could deploy a similar application on my handheld (leaving aside whether I stick with the BlackBerry or not), my choices are either to move the database onto the Internet where both my desktop and handheld device can reach it, or to set up another database on the handheld and figure out how to keep it synchronised with the one on the desktop.

For me, neither choice is optimal. Like many other authors of VB-based mission-critical applications, I'm not quite prepared for the challenge of locating my code and my database in two different places. The moment that a network is inserted between the two, my application must take on a degree of network awareness that I can't even begin to contemplate. Today, if I'm on an airplane, I can still process email with my CRM system. But if the data is on the network instead of in my local storage, then all bets are off.

One approach is to re-architect my application around salesforce.com. Salesforce.com offers some canned integration for both Outlook and the BlackBerry and has made its repository a Web service in a way that the code on my desktop might be able to directly access it. Unfortunately, since that approach requires me to programmatically deal with situations where the database can't be found, which in turn requires me to do some Java development on the BlackBerry, I'm not up to the challenge. One technology, however, that makes salesforce.com more palatable for offline operation is Dejima's Direct SFA -- a solution that can cache database queries and changes while my handheld (could be a BlackBerry or a PocketPC) is offline and then, when the handheld is back online, the central database is updated with the data waiting in the cache.

But going down that path would entail some expense that I'm not willing to bear. So far, to get where I am, I've spent nothing but time on getting increased productivity. Another problem is that, in order to work, my code requires real-time access to the data. The more I think about it, the more I realise I will need a local copy of the database on any device that's empowered with my application, and synchronisation of that database between the desktop and the handheld will be a requirement. This means coding on the handheld will be a must.

Things will have to be consistent between my desktop and my handheld. In the interests of my own time, I don't want to maintain two separate code bases in two different languages (VB and Java). Both devices will also require local relational databases that can be synchronised with each other.

I'm coming to grips with the reality that my initial reliance on Windows, which led to Microsoft Office, which led to Visual Basic, is now leading me further into Microsoft's walled garden. In order to stick with the BlackBerry, which I wish I could do, I'd have to switch to a mobile database technology that supports synchronisation and both Windows and the BlackBerry. The answer to that problem is something like iAnywhere's M-Business Anywhere. But, while M-Business Anywhere allows me to stick with the BlackBerry, mimicking the functionality of my Outlook-Access-VB application still requires me to enter the Java universe.

The plot has thickened to the point where I have two choices. One: Learn Java and redo everything I've done to date on the desktop using that language as well as other products (perhaps StarOffice or Novell's Ximian Revolution) that Java can automate. Two: Replace the BlackBerry with a device that's more agreeable with the work I've already done in VB, like Microsoft's PocketPC with its VB.Net-accessible .Net Compact Framework. There's even an open source-based Integrated Development Environment (IDE) that can ease this cross-platform (handheld/desktop) development called #develop.

To be fair to Java, the work I've done in VB isn't exactly reusable and there will be a learning curve involved, even if I stay in the Microsoft world. But the learning curve won't be as steep as it would be if I started from scratch with Java. The reason is that to do anything reasonably fancy with the message store on a PocketPC requires VB.Net, which isn't quite the same as the VB in MS Office that I started with. The logic will largely stay the same, as will some of the language's syntax, but the classes that expose some of the underlying functionalities that my code relies on are different. I'll have to figure them out and make some substitutions. Since .Net Compact is a subset of what's available on the desktop, the best way to go the VB.Net route will be to reprogram for the handheld first and then port it to the desktop. Going the other way runs the risk of using a class on the desktop that doesn't exist on the handheld because the footprint for .Net on the handheld has to be much smaller.

Of the two options -- Java and .Net -- the former has more appeal. While the latter allows me to get the job done, I don't like the condition of being so bound to Microsoft. For example, going the PocketPC route puts me one step closer to Microsoft's Mobile Information Server, which, like RIM's BlackBerry Enterprise Server, offers a more robust infrastructure for keeping a handheld in tune with data that resides on the corporate network including, you guessed it, Microsoft's Exchange Server. However, despite desperately wanting to go back to the door, pry it open and have all the non-Microsoft options at my disposal (thanks to the widespread support for Java), the head start I've gotten with VB is like the little devil sitting on my shoulder, beckoning me. Not to mention that, in addition to iAnywhere's M-Business Anywhere, there is a bunch of third-party products that will keep a PocketPC-based database synched with a desktop database (including Access). There's also Microsoft's desktop and PocketPC versions of SQL Server that can be kept in synch with each other as well.

Others, perhaps those who are developing mobile applications that target many more users, must be at precisely at the same crossroads as I am. For example, according to IDC Research, 13.08 million converged mobile devices shipped worldwide in 2003, a volume that amounts to 360 percent increase over 2002. IDC is forecasting that converged mobile device market will continue to expand at triple-digit year-over-year growth rates; a growth rate that far exceeds that of desktop and notebook PC's, which means that it won't be long until there are more converged mobile devices in use than PCs. Of the top programmable mobile environments -- Java, PalmOS, PocketPC, and Qualcomm's BREW -- Java, which can also ride on top of the Palm and PocketPC operating systems, is by far the biggest target.

The decision isn't very difficult to make. Despite the clear advantages of Java as well as the growing support for it, I'm not ready to start from scratch again -- especially since Java remains somewhat unapproachable. I may feel differently in a couple of years when Sun's Project Rave has delivered on its promise of making Java as accessible to mortals as Microsoft has made Windows and Office development through VB. But Rave -- now officially known as Java Studio Creator -- is taking baby steps. While Jonathan Schwartz, Sun's executive vice president for software, promised that Rave would make it much easier to script StarOffice, Sun officials have admitted that StarOffice in no way targets users who have gone down the path of customising Office to the degree that I have.

Earlier this year, Sun global market strategies senior vice president Larry Singer told me that "with StarOffice, we're targeting enterprises that buy 100,000 copies of MS Office, but maybe have 100 people that used all that fancy stuff and the macros. Let the 100 people pay the premium for Microsoft Office and let the other 90,000 pay for something that's fully interoperable at one-sixth the cost."

It's an interesting strategy, but I wonder if Sun is underestimating the desire on behalf of IT departments to support fewer, not more products for their user bases. If Sun is serious about getting enterprises to switch, then it also needs to, on a parallel track to Rave, figure out a way to smoothly transition custom-developed applications like mine to the world of Java. Otherwise, a lot of companies that see the benefits of switching but consider it too much work will listen to the devil.

Oh VB, you devil you.

Editorial standards