Recently I had a .Net application dumped in my lap; that is, I was forced to understand it, the server on which it resides, and the code it is comprised of.
I was petrified. A good part of being a good tester is understanding completely every nut and bolt that goes into what you are testing. How else can you set expectations? There can be no ambiguity.
What I found after a week or so is that my fears were (largely) unfounded. Once you get past some basic issues on web hosting and syntax issues it's pretty simple.
How do I put this? Hmmm. Once you put your Fox-brain aside and truly evaluate non-Fox project architecture and syntax you will realize just how clueless 90+% of these folks are. Once I understood the mechanics enough to assess the underpinnings I was struck by the realization that the average .Net developer may be much more addled on delivering a "best practices" solution than your average VFP developer.
This goes back to my assertions 5 years ago on the UT and elsewhere that the VFP community has (had?) a tremendous opportunity as architects to embrace the .Net way of life and kick-ass. I am more convinced as ever of this after the stuff I've had to go through the past few weeks.
Some of y'all know and embrace this already. Strahl and McNeish come to mind...
Forget translating apples to oranges and applying VFP architecture to .Net and the Web. Just look at what .Net and the framework has to offer and how you would approach a client solution at a high level.
The light will come on. And you'll be thinking, "Holy shit, why did I ever think this was hard?" Sure, sure you'll still be thinking (as I do) that there are far easier ways to do x, y, and z in VFP (and that's true) but if you get off of trying to decode every line of code you'll see it.
Go forth my VFP brethren and kick the .Net coders, who have far less experience in the real world as you do, in the teeth.
Subscribe to:
Post Comments (Atom)
3 comments:
John...
So in a nutshell, what you are saying is simply this - it is a good idea for VFP developers to get on track with .NET??? That is pretty much what a lot of said several years ago. I liked your statement "Once you put your Fox-brain aside." That for many - is pretty hard. I always called it "Thinking outside the Fox-Box". The fact of the matter is that regardless of the development community - there is a good deal of intellectual dishonesty with respect to the tool of choice.
With respect to the average VFP developer - ironicially enough - the biggest handicap is often data. Sure - VFP developers are good at munging data on a local basis. Get them to think about remote data in a way that appraoches true scaleability - now you have a big task in front of you!!
I can't disagree with what you posted. But I wouldn't ding VFP developers for not coming to terms with remote data and the like - I'd rather ding MS for not coming up with a more integrated and coherent data strategy.
I think I've only ever seen one VFP-head opposed to the idea of engaging dotNET. I've seen far more prophets seeking to validate themselves by implying that the VFP community is a great unwashed rabble that is opposed to change and needs to have its collective head pulled from the sand.
So here we go again, this time the implication is that the biggest "handicap" (nice word) for VFP developers is that they think local and aren't easy to teach about remote data or scalability. Unlike the prophet and his buddies who figured all this out years ago while the rest of the community was presumably still puzzled about how to use a light switch.
There are some things that .NET does really, really well. There are some things that VFP does far better. There are some things that Linux and php do really well too.
The real "shame" is that you can't discuss differences these days without prophets descending to claim ownership of really obvious ideas, causing dissent and claiming the annoyance they cause is because people are opposed to change, not because people resent being told they need help to tie their shoe laces.
Post a Comment