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

Question

Have a client thinking about estimating the cost of porting a project from language A to language B. What's the best way to put together an request for proposal to do this?

Answer 1

If the goal is simply to reproduce one application exactly into a new language I would suggest you talk your client out of that. Porting is one of the most dangerous things you can do because all those quirks that came up because they implemented in Language A may be relied upon by the end users, and suddenly you have to recreate them in Language B. Nasty stuff. Not to mention that porting is a completely sunk cost that they can never hope to recover.

I would suggest treating the project like any other and gather requirements and estimate as if the original didn't exist. You will likely find that the end user has a new perspective on the product since using it. If you're going to re-write it, might as well make it better.

Answer 2

If you already have a Perl code base, you know the lines of code (LOC) count. See if you can find an expressiveness comparison between Perl and Language B. Here's one for example.

Say Language B is Java. Then the guesstimated LOC for the port will be about four times the LOC of the original (expressiveness 6 versus 1.5).

Then use something like the Construx Estimate software in LOC mode to estimate how long it will take you (and how many people it will take).

That'll give you ballpark cost and time estimates, as well as some idea of how likely it is that you'll overshoot.

If you're already proficient at Language B and have run several measured projects in it, you can use the Construx Estimate software to calibrate for your team.

Answer 3

Joels most popular article, 'Things You Should Never Do' says it best: They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

If you do end up rewriting it, rewrite it properly and don't just port it:

• Which parts of the program are no longer used? Skip these parts.
• Which parts of the program are most important? Port these first.
• A new program, time to refresh the GUI and make it easier to use and more 'sexy'.
• Oh, is the huge time investment not better used to just add more features to the old code?

Answer 4

It's going to take a lot of time I reckon. You better be sure it's worth it. Try taking a section of the code and porting it. Multiply how long it took by the ratio of the lines of code you ported vs the total lines of code. It will give you a ballpark figure, the real one will be higher by some mulitple most likely.

Effectively you are writing the app again from scratch but have the requirements specified in another language, it's non-trivial.

Answer 5

I think first and foremost, you should really consider if this is a good choice. What are the advantages of using language B instead of language A?

I think IBM had an investigation which said that programmers write, on average, 100LOC an hour. There is still more into development than that, but the old architecture is still planned. Let's say 50% will be writing the code, as the program otherwise is still pretty much planned, right? (It could be so that you have a structured program and you want an object oriented one and that would be a larger task).

But if one would write 100LOC/hour, divide the amount of current LOC in the system and multiply it by the average sale of a programmer and multiply that by 2. This might give a rough estimate. Don't take the numbers you get very seriously. (even better, don't take them seriously at all). What you want to do depends on way to many things to simply measure, such as:

• The programmers competency in the new language
• How well documented the old project is
• Which language is being converted from, and which is being converted to?

Answer 6

It depends on how much time you have available. Some options:

• No time at all, just get it done - Take the back of a napkin and go to it. It's like to be less than it took to make it in the first place, and more than simply retyping it in a different syntax.
• 1-3 days - figure out what architecture rework might be required, take a stab at estimating. Figure out how much logic must be ported, figure out some sort of ratio. Add some extra time for security related tasks that will provide some hope that you've increased the security in the process. Add time for integration testing based on the complexity of the work and simplicity of your architecture.
• 1 monthish - try some - stage a test architeture, and try porting something. Figure out what fraction of the code you ported and estimate further. It's likely you'll also figure out a few things that were totally impossible in the new language, and it'll provide a better basis of the actual work involved in making the transition happen.

In an ideal world, I'd propose to the client that they pay for an investigation task to cover that one month of work to let you prototype just what you'd do. That gives them the option to halt and not go forward if the cost is too great. AND, you still get paid for the work you did.

Answer 7

There is only one way to get a decent estimate for a software task. Assign the available staff to do some small but testable part of the task COMPLETELY, and see how long it takes. Break the remaining work into as many use cases as you can, and have the same staff estimate each iteration in comparison with the work already done. Don't ask them to estimate time, just ask them to tell you how it compares with the first iteration. This will give you the best possible estimate for the rest of the project.