Skip to main content

Future of (your) Development Lies in You, Not Microsoft

By now, I hope most FoxPro developers (and others) have read the announcement and the various follow ups (and no this isn't meant to be link bait but more of an exhaustive way of reading about it all)

E-Week
Mary Jo
Craig Berntson
Yag's Thoughts and Comments
Alex Feldstein
Doug Hennig
John Koziol
Rick Schummer
David Stevenson
Randy Jean
Andy Kramek
Mike Feltman

and I'm sure there will be more before the week is up. As is always the case when these announcements hit, people will be asked "how could we possibly have been developing with a tool that's no longer around?"

I think Doug actually put it best when he said "I can continue to purchase VFP licenses for new development staff for several more years and I can continue to receive support from Microsoft until 2015. That's not definition of dead."

But in my correspondence with a colleague, yag's comment about resistance to learn a tool that is 18-23 years old (C and C++) instead of newer tools. How many applications used today were built with C and C++? Many of them are and continue to be - but I think most new projects are built using other tools. Even Java isn't as popular as it used to be when it was the "hot language du jour". Now tools like Ruby or Python are just as popular. And these are open tools - they are supported, not just by a vendor, but by an entire community.

Before I jump in on the community part, I also wanted to make a comment about Microsoft's development approach. They have a lot of great tools and amazing people. But one thing that has frustrated me and other developers is their need to continually RE-PACKAGE or re-design development approaches. And this isn't just with FoxPro and VFP. This is about development architecture. In the beginning was Client-Server, then DNA, then COM, then COM+, SOAP, etc, etc. You used to access data via ODBC, then ADO, now ADO.Net and now LINQ. You could build forms with VB, then in Visual Studio 2003, it was WinForms, and now it's WPF/E. And most of these changes in strategy have come out all within the past 10-15 years. This isn't to say they aren't good or great. But many of these changes weren't easy to bring about in existing code - they required redesign. The developers who jumped on one technology's bandwagon then had to be prepared to jump over to the next new one when it came out, because it was "going away". I'm all for "show me the best way to do something" but I think at times, Microsoft (and likely all developer tool companies) needs to realize that when a company makes an investment in a technology, when that technology changes even slightly, some managers go crazy and worry everyone with their "sky is falling" bit. That's not directly Microsoft's fault but it's a reality for many developers, especially those who spend 5 years learning a technology only to be told that it's not the right way to do it anymore. Sure, they have "experience" - but tell that to the 45-year old developer who is getting his pink slip handed to him because his manager loves the way the latest 20-year old builds his Atlas.Net application.

A better example : read Yag's post about Generation Y. here's just one take-away: "I worked with some interns who built an app and the first screen was just a search box - and it would search customers, inventory, orders, etc., and bring up appropriate ones. Very few menus - unlike in my day. "

Ten years ago, if you were asked to build a search screen in an invoicing application, the first thought would be at least 3 search boxes: customer, invoice # and maybe product.

And which one is better? Hard to say but the reality is that anyone with any exposure to the web (and that would be almost everyone in our area) is now used to a single search box.

Things change but also where they are being used also changes.

Development is about finding the right tool(s) for the right job. If you're building a new desktop application, you'll likely take a different approach than what you used ten-fifteen years ago. But if you've got a desktop application that works, you'll build on that foundation and make it better.

The computing desktop is going to change hugely in years to come. But it will take time. Microsoft has made noises to the fact that Vista (and its follow-up server) will be their last 32-bit operating system. Do YOU see yourself switching to a 64-bit computer in the next five years? I don't. Multi-core, etc - sure but 64-bit? Can you see most corporations changing in the next five years? Me neither.

But eventually, they will. But I would say that's a ten year timeframe, if not longer. By that time, what will a typical computer look like? Will the internet be everywhere via Wi-fi? I think the way businesses operate may also have changed by then so desktop applications may not be the best way for building a new application - maybe it's web or mobile or (and I shudder to think of it), on your phone.

There will still be a need for desktop applications (as they are thought of today) and Visual FoxPro can still build a killer desktop application. If you don't believe me, check out the work that the community, not just Microsoft, has done with VFPX. The work being done on Sedna is also community-driven - Doug Hennig, Rick Schummer, Craig Boyd, Lisa Slater and Colin Nichols among many others are the ones directly working on it. These aren't Microsoft employees. And while they work at Microsoft now, Yag and Calvin were also main individuals in the FoxPro community, pushing the product forward. No one thought that FoxPro could do the Internet until Rick Strahl made it easy. And the user interface work that is coming out of VFPX is completely amazing. If you wanted to build an Outlook-like or Office-2007 style application in FoxPro, people may have told you even three years ago you couldn't do it. Don't look now - you CAN! If you don't think that the community can make a difference, look at other community-based open-sourced products such as DotNetNuke, Ruby on Rails and the like.

Yes, the concept of an application will change - as developers (and as people), we have to be aware of it. But let's also keep in mind that just because the marketing message says "the old way is wrong", doesn't make it so. How many other "old" technologies are we still using and using well?

One day, we may not need a "car" as we know it - (I keep hoping Moller's SkyCar would do something but it doesn't look like it for a while), but as long as we have roads and the current infrastructure, we will so we keep on improving them but always within the boundaries of what is possible or effective. (UPDATE: there are a lot of other companies in that sector now)

With all of the changes that Microsoft has recommended over the years that I noted above, FoxPro has been able to take advantage of and it still does, mostly because of the innovations that the community has brought to it. Visual FoxPro is not the answer to every business problem - but neither is software alone.

Problems aren't solved by software - they are solved by people.

Comments

Anonymous said…
Hi Andrew:

I agree with you and I've made my choice with VFP, but I (and others) are very upset because they are going to drop a product that it is still very used!!
How can you explain that a company drop an active selling product?... The only explanation for me is that they don't want that people buy ths product and force them to buy another.
That's why everybody is upset, because they "force" you to change. I don't have any problems for the change, but I like to decide when to do it.
This decision impact many things:

- People at many enterprises are facing this "forced" change and now are thinking what to do with all the investment done, because the impact on the economics of those enterprises

- Some managers are going to fire VFP people and to employ another language people, just because don't need the extra cost of training the existing one

Don't they know that many enterprises buy an MSDN subscriptios because, among other things, VFP matters to?

They deserve to be legally demanded for the damage done.
Anonymous said…
Hi Andrew,
I totally agree with you. VFP will live as the desktop development lives!!!

Hi Fernando,
Fortunately, my boss pays me for making a good software product that can be sold to our customers. He doesn't care what tools I use -since he doesn't have to pay something more . Our scope is to finish the business (to make our clients happy) It is not the medium that makes the people happy but the final product!

BTW, I keep an eye on .Net and I hope until 2015 Microsoft to have a VFP equivalent product for the job.

Vassilis Aggelakos
Bill said…
Andrew, the one shining star in this otherwise dark last few days is the potential that placing VFP in the open source community has.

It also has a potentially huge downside, but, honestly, I don't know if it could get much worse, and, if some of the folks who've been working with the internals for years hang in there, it could be an entire 'breath of fresh air' for the future of VFP.

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Elevating Project Specifications with Three Insightful ChatGPT Prompts

For developers and testers, ChatGPT, the freely accessible tool from OpenAI, is game-changing. If you want to learn a new programming language, ask for samples or have it convert your existing code. This can be done in Visual Studio Code (using GitHub CoPilot) or directly in the ChatGPT app or web site.  If you’re a tester, ChatGPT can write a test spec or actual test code (if you use Jest or Cypress) based on existing code, copied and pasted into the input area. But ChatGPT can be of huge value for analysts (whether system or business) who need to validate their needs. There’s often a disconnect between developers and analysts. Analysts complain that developers don’t build what they asked for or ask too many questions. Developers complain that analysts haven’t thought of obvious things. In these situations, ChatGPT can be a great intermediary. At its worst, it forces you to think about and then discount obvious issues. At best, it clarifies the needs into documented requirements. ...

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction...