The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

converting legacy application to dotnet/java

our main application is written in powerbuilder and
we are moving on to either dotnet or java, leaning towards strongly dotnet at the moment (main reason, very difficult to get skilled powerbuilders)
We are also looking at switching our database from sql anywhere to ms sql express

anyway, what i am interested in is formulating a plan to handle the conversion.

Note that our app has had a lot of patches over the time and is starting to look like spaghetti code in a lot of places

we have two schools of thought

Option A - Phased release
1. convert the database first, alter the powerbuilder application to use the new db
2. convert the code, asis to C#, and get a working version
3. refactor/re-architect after everything is translated

Option B - All or nothing
1. take a look at the application and refactor/re-architect on paper
2. convert the code and database at the same time according to the plan
3. do a complete switch from old app/database to new app/database

I would appreciate any feedback, pros/cons of those two options, or perhaps even another option all together

thanks in advance
bumperbox Send private email
Wednesday, February 28, 2007
Assuming the existing system behaves as expected, can you start writing Unit Tests to validate this?  Converting Unit Tests over to a new codebase are relatively easy in the various xUnit frameworks.  Then, as you are supporting the old codebase (I assume you have customers using it), you can write every Unit Test twice... sure, it sucks, but it is an easy way to validate everything.

And then start moving over individual components.  If you can make the existing system pull from those new components, even better.

I've recently done a similar effort in Java->PHP.  The first step was taking some of the existing Unit Tests, converting them over and had our first pieces.  Then we found quite a few places where the Java was simply spitting out a data structure for the view to render.  We changes the Java to spit out XML and transformed it using XSLT.  Since XSLT is languages agnostic, we had another piece.

Then since we had a) Unit Tests and b) XML exchange, it was simply a matter of writing the PHP in a way where it was returning the same XML and could be retrieved via Java.

We're not done yet, but it's going relatively smoothly.
KC Send private email
Wednesday, February 28, 2007
"Option A - Phased release
1. convert the database first, alter the powerbuilder application to use the new db
2. convert the code, asis to C#, and get a working version
3. refactor/re-architect after everything is translated"

I'd modify this to:

1. Create a moderately sized suite of regression tests first.
2. Then do a cycle of refactoring on the existing code.
3. convert the database, alter the powerbuilder application to use the new db
4. convert the code, as is to C#, and get a working version
5. Optionally, another cycle of refactoring.

Doing them in this order, each step puts you in a better position to do the next step more effectively.
Rowland Send private email
Wednesday, February 28, 2007
Good advice from KC & Rowland.

I've worked a project  this before - took a plain client-server PB app to an intranet app.  My recommendations:

1) design the new system the way it should be done in your target environment.  DO NOT just port the PB structure.
2) (as advised) set up your unit tests early.
3) if you make extensive use of DataWindows, replacing them  will likely be the bulk of your work, time-wise. Deciding on a strategy early can save you a world of hurt.

Managed properly, this doesn't have to be a problem project.  NOT managed properly, well....don't do that!
a former big-fiver Send private email
Wednesday, February 28, 2007
What type of product is it? I think that matters quite a bit. I'm also assuming that you intend to keep it as a client/server application instead of changing it into some sort of web app. If not, that is important to know too.

I personally like option A better. But it would depend on how much business logic you have to port and how well your program is architected. If all of your business logic is strewn all over the place and written directly into DataWindows then you probably just need to start from scratch. If the application is already well architected with business logic sectioned off into user objects then the port will be easier. This is why the other posters are pushing unit tests. If your business logic is strewn all over the place then unit tests will be the best way to know that you've converted the code correctly.

The good news is that PowerBuilder is very similar to .NET in many ways. You should be able to get up to speed very quickly. I think that this speaks volumes about the PowerBuilder and how it was "truly OO" way before many of the mainstream OO products were invented.

Good luck.
dood mcdoogle
Wednesday, February 28, 2007
Before you switch and go through this aggravation, why are you doing it in the first place?

If there are indeed legitimate reasons, then we can give better answers.
Steve Hirsch Send private email
Wednesday, February 28, 2007
we are switching for a number of reasons
- too difficult to find staff that have heard of powerbuilder, let alone used it
- powerbuilder seems to be struggling to keep up with other languages in terms of innovation
- already have staff with C# skills
- hit limitations of powerbuilder gui wise
- dotnet has better web integration (in my opinion)
- microsoft controls the market, so why not jump on their back
Wednesday, February 28, 2007
Thought so (doesn't KNOW PowerBuilder, or staff don't).

Of course I'm not claiming I do either, thus it seems like a good reason. *wink*
l belk
Wednesday, February 28, 2007
I would actually change the phased approach to be convert the application to C# first.  When you do this create an abstraction layer above the database.  That way you will have a more organized area to work with instead of digging through the powerbuilder code and making sure that you get all the references converted over.

P.S. I both know what PB is and have experince with it.  Out of curiosity what GUI limitation have you run into?
Eric Matson Send private email
Wednesday, February 28, 2007
not all limitations are gui

some limitations are because we are running version 8
i haven't been all that impressed with the quality/scope of features in versions of 10.5 and 11 to warrant upgrading yet

- issues with selection of rows in dddw
- control of size of dddw's
- native dddw calendar control problems
- rtf editing
- datawindow reports page headers, page footers, report headers, report footers (without hack workarounds)
- text in datawindow columns is too close to the border unless you use system fonts, making it difficult to read
- no text on toolbar items (you can do text, but it is so small it can't be read, so whats the point)
- slow source control implementation
- slow build time
- tabs are difficult to implement
- sick of having to close all child objects to edit an ancestor and then do a rebuild to stop it from blowing up

i could go on for a lot longer, and i am sure vs2005 probably has a whole stack of issues and limitations too

i can live with all the limitations except for finding skilled staff for a reasonable price
Wednesday, February 28, 2007
Has your user community bought into this conversion?  Is the user base captive, i.e. in house or is it outside customers?

If this is a large application, trust me when I tell you that you will have fits and bad days trying to convert a PB application to .NET while retaining the functionality.  I have been in that boat.  I am aware of one large company that has been "converting" an application from PB to .NET for more than 2 years and has spent more than 10 million dollars in the effort.  They are not much closer today than a year ago yet they keep pouring money into the project.  And just because their CIO was told that Powerbuilder was an antique legacy language.

I developed in PB beginning with version 2.0 through 10 although I don't currently do new development in PB.  I have also developed in .NET.  For what it is worth, for pure client server (not WEB) development, there is nothing as efficient as PB.  I could develop a client/server app in PB in 25% of the time it would take in any other language.  And I am proficient in quite a few.

Of course, none of this matters.  If management has decided to convert, then they will. Damn the Torpedoes, full steam ahead.
ps Send private email
Wednesday, February 28, 2007
the app is sold externally, to a small client base. the clients couldn't care less what langauge the program is written in, as long as it does what they want

we are only a small company and a small product in that sense

i have estimated it will take 2 developers 2 years, using a staged approach as per my initial post

we are not in a huge rush as long as we make constant progress.
Wednesday, February 28, 2007
Live with the PowerBuilder. Find people who are interested in your application, and train them on PB. You will be sorry.
Steve Hirsch Send private email
Wednesday, February 28, 2007
The problem here is how rich of a application that PB application is. I would certainly build a good data model document. I wouuld then start to look at the number of features that will take code to accomplish.

The other factor is how familiar are you with the existing application. If you never seen it before, then it hard to know the scope of the application. The more you know the old application, the better you can move this forward.

Also, how rich is the reporting side of this system?

So, what do you plan to use for your report writer? (and, how much experiance do you have with whatever you plan to use for reports?). This is important issue.

I only warning sign here is that PowerBuilder was rather productive tool, and in the hands of a good devleoepr..a LOT features may have been implemented over the years….

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Thursday, March 01, 2007
We always prefer something closer to your option (a). The key for us is the refactor *after*. In our experience, there's far less risk in (as much as possible) doing a 1-to-1 conversion of the functions/objects/code etc. and then, only *after* it's up and working appropriately, begin to refactor to take advantage of the new platform.

If you redesign/refactor as part of the actual platform switch, you're adding significant complexity (and *risk*) to the project.

Just my opinion.
Thursday, March 01, 2007
The main concern is that re-implementing an application in a new language is notoriously a waste of money, especially when your existing customers only care that it works.

This might sound a bit wild, but is it possible to find a segment of your customers or a new but related customer need and set off with a new team building specifically for that? In other words, maintain your PB app for current customers, but spend your new development money on capturing a new market segment? And integrate them via webservices if need be? The masterplan would be that once it is successful, old app functionality could be added in until your original customers see the value of moving over.

Say a company sells a cell phone model, but one of the most common customer requests cannot be implemented because of a platform/component conflict. So they split off a team to develop a new cell phone model centered around that specific feature. They expect a few customers to move over as soon as you can get the new model out, but they also expect to capture new customers who never bought the old model because of that missing feature.

Also, concentrating on that new feature freed them from trying to catch up with the old model and allowed them to get to market more quickly. Remember the old model is still being maintained and updated to keep the original customers happy enough, so it is a moving target.
Ben Bryant
Saturday, March 03, 2007
I'm finding it difficult to believe that it is more economical to rewrite than to bring in PB contractors from whereever to maintain this application. Plus you'd be surprised how many people would take on learning PB so to get their foot in the door in high tech.
cbmc64 Send private email
Wednesday, March 14, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz