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.
Wednesday, June 20, 2007
Monday, June 18, 2007
The World of Tomorrow, Part Five
So as I last left you I mentioned two current buzzwords making the rounds: RIA and SaaS.
Upfront, I am going to ignore a lot of the theory and CIO-gibberish both of these areas and focus on what's important to the VFP developer.
First off, RIA. In plainspeak, RIA is an attempt to make browser based apps look and feel like rich client apps. Those of you who have paid attention to the last few years of VFP soundbites (which I helped write) will note that rich client apps were a selling point of VFP.
RIA is, potentially, a great direction for VFP developers to go towards. The tools insulate the developer from the background mechanics and allow the developer to focus on the business process. I go back to a previous analogy - do we want to build bricks? Hell, no, we want to build houses.
I'm time curtailed tonight....read up on RIA and think about it. More later.
Upfront, I am going to ignore a lot of the theory and CIO-gibberish both of these areas and focus on what's important to the VFP developer.
First off, RIA. In plainspeak, RIA is an attempt to make browser based apps look and feel like rich client apps. Those of you who have paid attention to the last few years of VFP soundbites (which I helped write) will note that rich client apps were a selling point of VFP.
RIA is, potentially, a great direction for VFP developers to go towards. The tools insulate the developer from the background mechanics and allow the developer to focus on the business process. I go back to a previous analogy - do we want to build bricks? Hell, no, we want to build houses.
I'm time curtailed tonight....read up on RIA and think about it. More later.
Sunday, June 10, 2007
Oracle, Unchained
I was at a presentation recently where Oracle's chairman was quoted as a fount of knowledge in an emeging technology.
Ellison? Doesn't anyone remember that everything Oracle has ever touted outside of databases has been shit?
I dread the moment that Oracle might wish to move to Atlanta and merge with Computer Associates. The merger of those two would create a state of negative energy in the universe and flip us into the true vacuum state where the universe would restructure itself to the lower energy level and destroy us all.
But before that happened there would probably be time for workers to put the new sign of the merged company on the side of the headquarters building:
SUCK Incorporated.
Ellison? Doesn't anyone remember that everything Oracle has ever touted outside of databases has been shit?
I dread the moment that Oracle might wish to move to Atlanta and merge with Computer Associates. The merger of those two would create a state of negative energy in the universe and flip us into the true vacuum state where the universe would restructure itself to the lower energy level and destroy us all.
But before that happened there would probably be time for workers to put the new sign of the merged company on the side of the headquarters building:
SUCK Incorporated.
The World of Tomorrow, Part Four
Funny enough, it was Visual FoxPro that was labelled difficult to learn and master. A Fawcette Technical Publications review of Visual FoxPro 6.0 in 1998 referred, tongue-in-cheek, to it's "simple, 5 year learning curve".
Yet, is it really that difficult? It can be, depending on what you need to do or on the standards expected by your client. For simple applications, though, it isn't very hard at all.
Contrast this with .Net. While the Designers are similar to the VFP Designers, the code behind the pretty pictures is daunting. Yes it's elegant and flexible, yes it's powerful but it's very difficult to do simple stuff that's not drag-and-drop from a toolbox.
Many of the VFP developers I have known really love the cool things you can do in VFP ... but usually don't have to. They'd much rather tweak their class and function libraries to do the grunt work and concentrate on the business task.
VFP developers, for the most part, freely give away their secrets and that overcomes a lot of the language difficulties. Those that charge for their wares do so because of their huge investment of time in their work and no one would expect less. VFP developers do not have to invent the brick to build their houses....unless they want to.
Not so in the .Net world. You may not want to invent the brick but few are going to give it to you. There sure are a lot of brick assemblies for sale, though. Good thing, because it would take you a long, long time to build that brick and you better have a good grasp of chemistry and engineering to do so.
In the last 18 months, I have led or managed small and medium sized development teams on monster .Net based projects, using ASP, C#, web forms, win forms, secure sockets, etc etc etc. The developers I work with are very talented folks. But I have had to really lower my expectations on the quantity of deliverables and the robustness of the initial builds. It is so, so easy to "blow up" Visual Studio apps because the amount of things the developers have to account for sometimes overwhelms them. A small behavioral tweak may cause 2 or 3 developers days to complete.
I can't even begin to describe how hard it is to get a robust, blind installer in place for these applications.
Upper management gets frustrated, understandably. They can't fathom at the gut level why it takes so long to deliver functionality that used to be delivered in a fraction of the time.
There are those in the VFP world who have transitioned to the .Net world and I say God bless 'em. If that's the tool that meets their needs, all power to them.
But I think the backlash "for the rest of us" is coming. Two acronyms: RIA and SaaS.
RIA (Rich Internet Applications) tools make it easy to put robust line-of-business applications up on the web quickly and with a minimum of fuss. SaaS stands for Software as a Service and is defined as centralizing data and code and selling business software subscriptions. There are several maturity levels of SaaS but, in the end, it deals with removing local, complex software and managing changes and customizations by scripting and configuration management.
Where does the VFP world fit in and what are the advantages for VFP developers looking for their next platform?
For that you have to wait for Part Five. Gotta go buy summer school clothes for my daughter.
Yet, is it really that difficult? It can be, depending on what you need to do or on the standards expected by your client. For simple applications, though, it isn't very hard at all.
Contrast this with .Net. While the Designers are similar to the VFP Designers, the code behind the pretty pictures is daunting. Yes it's elegant and flexible, yes it's powerful but it's very difficult to do simple stuff that's not drag-and-drop from a toolbox.
Many of the VFP developers I have known really love the cool things you can do in VFP ... but usually don't have to. They'd much rather tweak their class and function libraries to do the grunt work and concentrate on the business task.
VFP developers, for the most part, freely give away their secrets and that overcomes a lot of the language difficulties. Those that charge for their wares do so because of their huge investment of time in their work and no one would expect less. VFP developers do not have to invent the brick to build their houses....unless they want to.
Not so in the .Net world. You may not want to invent the brick but few are going to give it to you. There sure are a lot of brick assemblies for sale, though. Good thing, because it would take you a long, long time to build that brick and you better have a good grasp of chemistry and engineering to do so.
In the last 18 months, I have led or managed small and medium sized development teams on monster .Net based projects, using ASP, C#, web forms, win forms, secure sockets, etc etc etc. The developers I work with are very talented folks. But I have had to really lower my expectations on the quantity of deliverables and the robustness of the initial builds. It is so, so easy to "blow up" Visual Studio apps because the amount of things the developers have to account for sometimes overwhelms them. A small behavioral tweak may cause 2 or 3 developers days to complete.
I can't even begin to describe how hard it is to get a robust, blind installer in place for these applications.
Upper management gets frustrated, understandably. They can't fathom at the gut level why it takes so long to deliver functionality that used to be delivered in a fraction of the time.
There are those in the VFP world who have transitioned to the .Net world and I say God bless 'em. If that's the tool that meets their needs, all power to them.
But I think the backlash "for the rest of us" is coming. Two acronyms: RIA and SaaS.
RIA (Rich Internet Applications) tools make it easy to put robust line-of-business applications up on the web quickly and with a minimum of fuss. SaaS stands for Software as a Service and is defined as centralizing data and code and selling business software subscriptions. There are several maturity levels of SaaS but, in the end, it deals with removing local, complex software and managing changes and customizations by scripting and configuration management.
Where does the VFP world fit in and what are the advantages for VFP developers looking for their next platform?
For that you have to wait for Part Five. Gotta go buy summer school clothes for my daughter.
Saturday, June 09, 2007
The World of Tomorrow, Part Three
First off, I apologize for letting this drag on. I have been very busy with the 9-5 stuff.
In plain English: The fear amongst Fox-ers is not the language. An experienced FoxPro developer has no problems with VB or C# when it comes to the language. The fear is the .Net Framework itself.
And it's not just old Foxheads. I was involved in a discussion the other day with C# developers where nobody could figure out how to make a label transparent to it's container. Trivial stuff in the Fox world, but apparently in the Framework world it demands an intricate knowledge of dithering and other shit unless you want to hard-wire the color. Which runs counter to the OOP abstractions Fox-ers have been preaching and living by for 10+ years.
This is a big problem.
Alan Cooper once said, and I'm paraphrasing, that Microsoft gave you the periodic table and you had to make a broccoli. But this was in the early 90's when VB developers were just as removed from the intricacies of the OS and OS theory as the VFP folks are now.
Unless you have an in-depth appreciation of the way everything should work in the world of Windows or IE based net apps - which a lot of line-of-business Fox folks don't - you are screwed.
I think it also explains the massive drop-off of VB 6 hobbyists from the fold. Things that were simple are now inordinately complicated.
In plain English: The fear amongst Fox-ers is not the language. An experienced FoxPro developer has no problems with VB or C# when it comes to the language. The fear is the .Net Framework itself.
And it's not just old Foxheads. I was involved in a discussion the other day with C# developers where nobody could figure out how to make a label transparent to it's container. Trivial stuff in the Fox world, but apparently in the Framework world it demands an intricate knowledge of dithering and other shit unless you want to hard-wire the color. Which runs counter to the OOP abstractions Fox-ers have been preaching and living by for 10+ years.
This is a big problem.
Alan Cooper once said, and I'm paraphrasing, that Microsoft gave you the periodic table and you had to make a broccoli. But this was in the early 90's when VB developers were just as removed from the intricacies of the OS and OS theory as the VFP folks are now.
Unless you have an in-depth appreciation of the way everything should work in the world of Windows or IE based net apps - which a lot of line-of-business Fox folks don't - you are screwed.
I think it also explains the massive drop-off of VB 6 hobbyists from the fold. Things that were simple are now inordinately complicated.
Subscribe to:
Posts (Atom)