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

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.