Visual Studio Vs Powerbuilder

[Former Member]

ok guys,

I have to prepare for a session to a meeting where I have to convince developers to switch from Visual Studio to Powerbuider.

Can you give me 10 good reasons for the mission?

ty

GMY

[Former Member]

We are trying to figure out whether to continue with PB or convert all our programs in VS / Java.

we run an entire system:

- accounting

- warehouse

- orders

- bubbles

- Invoices

- statistics

- MRP

- etc.

A very large project started with PB V3.0A and currently in development on PB 12.1

i'm so sad in PB

The team consists of 10 programmers.

[Former Member]

If the code is already in PowerBuilder then converting the applications you have to VS and/or Java is going to cost a HUGE amount of money, the applications will run many orders of magnitude slower (which will then require significantly more money to buy faster hardware), and like as not, NEVER GET DONE.

I cannot tell you how many projects I've run into where PowerBuilder applications were being "sunset" in favor of Java and/or VS and where the "new" application was subsequently cancelled due to cost and/or lack of performance, leaving the PowerBuilder app still running many years after it was supposed to have been replaced.

True story; my current main client brought me on back in 2008 to baby-sit their customer service application (written in PB 10 and supporting 500+ users) for the last year of its life while the new Java app was being finalized.  Due to budget cuts they let me go in 2009 figuring "enough" had been done to allow the PB app to live long enough.  In 2011 they brought me back part time to upgrade the app to PowerBuilder 12.5 and Windows 7; a project which I completed in a whopping 29 hours.  As they had budgeted 1,000 hours for me to complete the project, they just kept handing me bit work to keep the app limping along until its (new) scheduled retirement date of 2013.  Not surprising, my part time gig got extended into 2012 and then 2013 with the sunset date being extended to 2014.

Two weeks ago it was revealed that the Java app had thus far consumed between 45 and 60 million dollars (depending upon which group you talk to), and after all of money and years of development it was still only able to do about 25% of what the PowerBuilder app could do.  Needless to say, when the gross expenditures leaked out, there was a management shakeup and within days the new Java application was "suspended" until further notice.

And the PowerBuilder app?  It is now the "new" (again, it was initially developed back in the PowerBuilder 3/4 era) enterprise customer service application; I'm suddenly being handed more than enough work to keep me busy full time and it looks like we're going to be nosing around for another PowerBuilder resource by year's end.

[Former Member]

Definition of "legacy application": that boring old software that actually runs your business. I suspect the key phrase in your post is "nosing around for another PowerBuilder resource" - management has a factory mindset and wants an environment where the supply of workers is boundless and wages are low - e.g. Asian manufacturing. So the problem is that many of the most productive, engaged PB developers have tired of maintenance and moved on to where they perceive the fun is, and the pool has not been refilled with eager graduates. It remains to be seen whether SAP can reverse that with the university partnership program, and marketing tools to bring back mind share. For instance, how much would it cost to fund an updated "PowerBuilder for Dummies"?

[Former Member]

For whatever reason, I have not had too much of a challenge finding PowerBuilder programmers over the last five years or so.

The thing is, while it is true that the quantity of qualified candidates is fairly low, the quality of said candidates seems to be rather high.  Speaking strictly for myself, I find it easier to choose one highly qualified candidate to hire out of a pool of say ten then it is to choose two or three moderately qualified candidates out of a pool of hundreds.

Recently I was talking with a developer I'd worked with on a PowerBuilder project back in the late 1990s and was suggesting to him that he'd have an easier time of finding a good paying PowerBuilder contract than he would say a .Net project.  He was initially dismissive of my premise, however, he'd been without a contract for several months at that point; two weeks after he re-added PowerBuilder to his resume, he landed a nice gig.

Sometimes it pays to work in niche areas. 

[Former Member]

Rewriting a software really goes beyond language problems.

There is nothing so "special" in what Powerbuilder actually does, that cannot be replicated in other languages (C++ for instance), given time.

The problem is that if you have a working enterprise-class software, it is almost always non-sense to rewrite it from scratch just because another IDE/language is fancier. If you are going to do a completely new version, with a new project, rethinking the whole software, there are many things that can go wrong, from analysis to implementation.

The biggest black hole that can drain all your energies and money is backwards compatibility.

Why would you rewrite a software that "just works" and has been tested for 5,10,20 years with a completely new one? Is there no refactoring or wrapping to simply make it better? Some bank and big assurance firm still rely on COBOL software on mainframes. Why? It just works.

The second trap comes in when you just realize you have big problems. You have to stop, talk with people, try to solve the puzzle and see if it's still a good idea. But you have to realize this before it is too late. Don't get emotional when marketing people tell you your software is old, it's the worse thing you can do.

In most cases, if your software is just modular and multitiered enough, you can make the new project and the old one cooperate side by side. If you write all the code in global functions called directly by datawindows, and have no framework to help you abstract your architecture, you cannot expect migrations to be easy.

Try to isolate the features you miss in your current PB environment. Regexp? Web? OLE?

You can start from those to build a complementary part in Visual Studio.

You can build a standalone PB.NET target and import your .NET assemblies... or viceversa.

You can build a Windows/Apache/whateverDB/PHP stack and get data from Powerbuilder through PB web services

Write tests that your actual software passes before dismantling any old code, so when you have a new software, there must be no regression - and if there is, you must know exactly where.

There is no "magic switch" turning a PB application into fully functional and 100% performing .NET/Java/Javascript/PHP/Python/Ruby/Haskell one in two days' time.