Programming time schedule for porting a program.

Question

I'm working on a large program which has an abstracted GUI API. It is very GUI based, many dialogs and a few nasty features which rely heavily on the message flow of the GUI (correct sequences of focus/mouse/active handling etc.) - not easy to port

I now want to port it from the currently used FOX Toolkit to native Cocoa/MFC.

I give myself a timeframe until the end of the year but my main work will be to continue development work with the existing toolkit, but there is no planned release for end customers before both tasks are done.

My question is how should i spend my time?

1. Stop working on the main program and do a 90% port (about 3 month) of the GUI first
2. Splitting everything into smaller sessions of one month each.
3. Assigning Monday/Tuesday to the GUI project and the rest of the week for the app.
4. Finishing the App first, then port.

I think there are three arguments which i need to balance.

1. Motivation, i want to see something going on on both projects
2. Brain Input Overflow, both tasks require a lot of detail information in my brain and sometimes enough is just enough.
3. I guess the porting is intervowen so porting would also require a lot of code changes in the existing code and the new code that will be written in the meantime.

Answer 1

I would finish the app first, then port it. IMO, the less projects you handle at the same time, the more effective you are.

Answer 2

It really depends on what you are comfortable with.

Personally, I would start porting now - a subsystem/piece at a time. You don't have to get the whole thing ported in one shot. You might find that the foundations of your application have to be rewritten to support being ported. If you wait until finishing the application to do the port, you may end up rewriting large portions of the app anyway. So I'd start by porting supporting libraries and core functionality, then slowly work to the edges.

In the meantime, each time you introduce a new class to the non-port make sure it is portable from the get go.

Answer 3

If there is no planned release to the customers then you have the luxury of being able to structure the work exactly as you wish.

My first impression is that putting effort into finishing the app on the current platform, when you're going to throw that code away, is time at least partially wasted (you get some learning but the ultimate code is of no use).

Personally I'd park the existing version and start over with the Cocoa rewrite.

First up I'd divide it into functional chunks and view each one as an agile style release. These should be focused on end user tasks and functions and including both the GUI and back end work for these.

(The reason I don't like the idea of working through the GUI and app logic separately is that they're not separate. As part of a rewrite there may be opportunities to make improvements and this is harder if you're having to keep them compatible. A rewrite is an opportunity to make fundamental changes that doesn't often come along - I'd take it).

Work through the functional chunks one by one, getting it to a complete, releasable state before you move on to the next one. This will give you both the sense of achievement and the ability to measure progress. It also means that if an implementation looms out of nowhere you have complete usable chunks.

Also, by focusing on end to end tasks, hopefully the mind overflow stuff is minimised as you're always working within a single specific area rather than across the app.

Answer 4

I started with one month each for MFC, Cocoa and GTK to do the basic stuff. And after this one week cycles among the systems to get the GUI abstraction layer. I haven't touched the application itself yet.

This was pretty efficient. Even when the complexity of MFC, Cocoa and GTK makes the typical monday morning when i do the switching even worse.

And i now know a lot how i have to change my application. I will port the GUI toolkit before i continue adding features because as Jon mention i would otherwise have to write parts twice.