-1

Possible Duplicate:
Best way to estimate cost related to porting code from language A to language B?

We have an MFC C++ program with around 200,000 lines of code in it. It's pretty much finished. We'd like to hire someone to convert it to work for Macs, but we are not sure how to properly estimate a reasonable timeline for this project.

What techniques can we use to estimate what it would take to convert this project to work on a Mac?

Also, is there anything in particular we should be watching out for specific to this sort of conversion?

  • 3
    If `Quality is important` you shouldn't judge a piece of code by it's size. An estimate is impossible if you don't tell us what these 200,000 lines of code actually do. – yannis Nov 27 '11 at 03:58
  • Justin: As noted by @Yannis Rizos I would suggest that you add more information to the question. With some luck we should be able to get you information about estimation techniques that you can then apply yourself. – Martin York Nov 27 '11 at 06:38
  • @LokiAstari For what it's worth, I also voted to close the original question. And although there are definitely standard industry techniques for cost estimation, I don't think they include porting especially when porting to another language. You could do a guesstimate based on the relative expressiveness of each language, but that's more of a hack than an industry standard. – yannis Nov 27 '11 at 06:56

1 Answers1

3

The first thing I'd do in trying to estimate the amount of work involved in this or any port is to figure out how much of the code needs to change and how much should work unmodified on the target platform.

If half the code is platform-neutral, the size of the porting project changes accordingly. It may be worthwhile to refactor the code on the original platform to make more of it platform neutral and achieve better separation between the platform-specific part and the platform-neutral part. You might consider that work to be part of the porting project, but it can be done by developers working on the original platform using tests that already exist. This approach lets you use the expertise you already have to best effect, saves time and money during the actual port, and leaves you with a code base that's partly shared between the two platforms, making it easier to keep the two versions in sync.

The next thing to do is to figure out how you want to implement the port. Do you want to rewrite the UI using Objective-C and Cocoa? Do you want to try to use some sort of compatibility tool that lets you build MFC on Mac? Do you want to port to Java instead, so that you can run anywhere? The degree of similarity between the original and target platforms will of course have a big impact on the amount of work required. If you can more or less use the original code as a template for the port, that'll speed up the work.

Evaluate your product's use of user interface conventions on both platforms. How much are you willing to change your product to make it feel less like a ported Windows product and more like a Mac product? Again, a straight port will be simpler, but may not fulfill your customers' expectations of what a Mac version should be. Certain differences (e.g. the Mac's Services menu) may not cost much because they're more or less automatic, while others (possibly undo support) may be a lot of work. Don't forget to factor in the cost of reworking graphic elements that can't be reused. For example, Windows applications often use ribbon bars full of tiny icons that would drive most Mac users nuts, and those icons may need to be redrawn for a better effect on the Mac.

These things will all help you understand what you want and what parts of the project are likely to be most difficult, but you'll probably still only end up with a ballpark idea of how much work is involved. If you're going to hire an outside firm to do the port, get estimates from several firms. If they mostly agree, you can feel better that the estimates are reasonable.

Caleb
  • 38,959
  • 8
  • 94
  • 152