Microsoft Visual FoxPro: this name brings a smile to my face, but sometimes for my customers it can bring a frown (and potentially lots of shouting, insults, and an overall bad attitude).

Why? If I’ve done everything right, my customers will never know the app was written with Visual FoxPro. But, if I’ve done something wrong, there’s a good chance they may see something like the image (or, worse yet, a lovely C0000005 message):

There are several reasons why I prefer my customers to not know their app was written in Visual FoxPro. Let’s start with the obvious:

1. FoxPro is old
   FoxPro has been around forever (FoxBase since 1984, FoxPro since 1989, and Microsoft FoxPro since 1992, even Visual FoxPro is over 16 years old – an eternity in the PC age). How many times have you heard, “But FoxPro is so old”? Sure, we can use phrases like “stable” and “mature” as adjectives to describe FoxPro. But, Tom Brokaw is “stable” and “mature” (and 72 years-old). I’ve heard the “FoxPro is old” statement numerous times over the past few years, in part because,
2. Microsoft dumped FoxPro, and there will be no more new versions
   How many times have you heard this one from clients, potential clients, users and (especially) other programmers? And, they’re right. Visual FoxPro 9.0 Service Pack 2 is as far as it goes, and it was released over 4 years ago. The most recent hot fix was released 3 years ago. Sure, there’s extended support for Visual FoxPro until January 2015, but that is only three two years away. There are no new enhancements coming. With no new enhancements, we’re kind of stuck with what we currently have: a development environment and runtime that was developed primarily for running on Windows XP (a 10 year-old operating system), along with several enhancements in Service Pack 2 to lead us towards better Vista (two versions of Windows-ago) compatibility. Be honest, how quickly did you download the Windows 8 Developer Preview, just to see if your VFP app would run as-is? I did, as soon as it was available for download. But still, even with the Vista-compatibility enhancements, many people look at apps written in Visual FoxPro and think,
3. “It’s ugly”
   Some people “hate THE FoxPro” because they believe “the FoxPro” makes ugly apps. This is, of course, not true. We have all the power that Visual FoxPro provides to create compelling, modern, and usable interfaces. But, as Uncle Ben told Peter Parker, “With great power comes great responsibility.” Visual FoxPro gives us great power, but it is our responsibility as VFP developers to make sure “THE FoxPro” doesn’t make ugly apps. Some people “hate THE FoxPro” simply because they think the ugly, buggy app they are running is FoxPro. Some people “hate THE FoxPro” because every time their app dies it dies with the aforementioned “Microsoft Visual FoxPro has stopped working” or “Microsoft Visual FoxPro has closed unexpectedly”. There’s one more (very personal) reason I don’t want my users to see “Microsoft Visual FoxPro” in my app:
4. If they have a problem with my app, they might Google “Microsoft Visual FoxPro” and end up on a FoxPro forum – asking questions of my peers about why my “piece of crap” app doesn’t work. Yeah, I’ve had this happen. More than once. Try Googling your apps’ name and see if any of the results point to the Universal Thread, Foxite, or the VFP forums at MSDN. It’s embarrassing, humbling, and a painful reminder that I’m not quite as smart as I’d like to think I am.

This makes my number one development priority (and #1 Tip): “Lose THE FoxPro“.

Which, coincidentally, is the title of my next post.