The Future is Cloudy

Andrew MacNeill, a good guy, has been commenting on my World of Tomorrow posts. He brings up some legitimate points but I'm not sure he understands where I'm coming from. Or maybe he does. Andrew, if you see this, please comment?

The ambiguity may be my fault because with my recent promotion to QA Architect (new responsibilities) and my hectic homelife, I don't always flesh out my positions well. Being borderline crazy doesn't help either (heh).

I am fully aware of what's in CodePlex and I have availed myself of some of those cool tools. There are some great, great resources there and other sites that are free to use. Still, though, no framework or tool is going to completely insulate you from the .Net Framework and some of the (to a Fox guy) weirdnesses to be found there.

We need to take a step back here; most VFP developers of my age or older - the majority - came into the profession from others. There were (and are) no schools teaching Visual FoxPro in the US, although I have heard it's used in some Indian high schools. A lot of VFP developers became VFP developers because they had a burning need to solve a business issue and bootstrapped themselves into becoming developers.

This is probably why, it seems, the intersection of C++ and VFP developers is in my experience small. C++ developers started out wanting to be developers and it requires a good grasp of professional development skills to accomplish things in C++. They are further down the abstraction ladder from concept to end-user than VFP developers. They think differently.

Now, consider the planning that goes into a VFP line-of-business application as opposed to the same planning if one were to write a line-of-business app in C++. VFP does so many things for you that you can focus mainly on the functionality. With a C++ app, you have to spend a large percentage of your time thinking about housekeeping, memory management, database connectivity and concurrency...it boggles the average VFPers mind. And in my experience, it sometimes boggles the C++ developers mind as well.

I mean, nothing against Craig Boyd, but why in the hell does one want to mix XAML and VFP in the real world? Sure, it's a great intellectual exercise, but if XAML is where you want to go why involve VFP whatsoever? And why XAML? The builders are not there yet so there's a lot of hand-tooling...something VFPers generally detest.

Why not Adobe Flex and FlexBuilder? You have the simple object model and a great builder tool. Something VFPers like and can work with and, since it's RIA, a good foundation for the future.

On the opposite end of the equation, why not use FileMaker for Win apps? Simple, built-in DML...perfect for solving small or medium business issues.

My point here is that .Net architecture just doesn't work the way most VFP developers are comfortable with. There's too many moving parts. Simple issues become consumed by the sheer complexities of the platform. VS 2008 will solve some of these issues, ie LINQ, but not all of them.

.Net can do things that VFP developers have a very hard time with. But the opposite is certainly true as well. So why the push to move VFPers to the .Net platform unless it's a mainly marketing exercise?

Let me return to my last "WOT" post: RIA. Adobe Flex and MS Sharepoint and Sharepoint add-ons represent means to create rich-content business apps by making available a variety of canned widgets to simplify meeting business needs without complex coding. This is really all that a monolithic VFP developer looking to migrate his app to a future-oriented platform may ever need.

But there's also the "if it ain't broke, don't fix it" school. If your VFP app rocks, you're happy, your clients are happy, and you don't see difficulties ahead with Vista - ROCK ON! Sell those apps, keep the world happy, and don't embark on switching tools if you don't have to. Introducing risk out of fear and not need is a cargo cult-ish anti-pattern. Can you count the number of disasters you've seen because some bozo decided they had to use the newest and greatest for a project when they didn't have to and, subsequently, damaged or killed the project? I have seen my fill of those.