Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 6 down vote favorite

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?

share|improve this question
3  
Why do you need to do that? It is hard for me to imagine it being a good choice. – Anto Mar 11 '11 at 19:55
+1 @Anto: Language A is in Perl, client is concerned about the security of the code base running on a remote server. Thanks! – blunders Mar 11 '11 at 19:59
Better you should simply ask "Best way to estimate cost?" That's equally impossible to answer. – S.Lott Mar 11 '11 at 19:59
2  
@blunders: work up an estimate for doing a full security audit of the code base, and then multiply that by 50. – Carson63000 Mar 11 '11 at 20:13
1  
It should take 6 to 8 weeks. Or use this tool: cznp.com/6to8weeks/index.php – JohnFx Mar 11 '11 at 23:30
show 2 more comments

7 Answers

up vote 10 down vote accepted

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.

share|improve this answer
3  
TDD is a pretty sound approach. Summarize some use cases. Define some tests for those use cases that the existing code passes. Write new code which passes the tests. Use the old code as a kind of "referee" or "umpire" if there are questions on edge cases. – S.Lott Mar 11 '11 at 20:13
@S.Lott: pretty tough to TDD the end user's experience. – qes Mar 11 '11 at 21:07
@S.Lott: I think the issue here is that languages have quirks. Doing something the natural way in Perl is likely to produce odd behavior in corner cases, and reconstructing this exact behavior in, say, Common Lisp is going to be awkward. Unless you know whether the user is relying on this behavior or not, you don't know what to test. – David Thornley Mar 11 '11 at 21:08
@qes: If you can't test it, it doesn't exist. Seriously. The end user has to "do" something. And that something has to be tested. Without testing, how do you claim that it's "done"? – S.Lott Mar 11 '11 at 21:08
1  
@S.Lott: That's what IBM wanted to do with the IBM 360 emulation of (IIRC) the earlier 7094 computers. They found that some of their customers relied on undocumented features that were accidents of 7094 implementation, and wound up replicating a dozen or two behaviors that they thought unnecessary. – David Thornley Mar 11 '11 at 21:16
show 4 more comments
up vote 3 down vote

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.

share|improve this answer
1  
Yeah, then multiply that estimate by 2 or 3 to account for the inevitable foul-ups, things you didn't understand, more powerful server you need to buy, extra coffee, painkillers for the headaches, and so on. – quickly_now Mar 12 '11 at 0:07
@quickly_now : agreed, but the Construx Estimate gives you a range of possible times, which accounts for some of those variations. That's part of what I like about it: it doesn't give THE estimate. It gives a range. – Peter K. Mar 12 '11 at 0:35
up vote 2 down vote

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.

share|improve this answer
+1 @Alb: Agree, about taking a chuck of code as a test. My plan was to include a chunk of Perl code (200 line) in the RFP and require a port with the responding bid. This will also allow me to compare the code among the offers, since they'll all get the same chuck of code. – blunders Mar 12 '11 at 2:45
up vote 1 down vote

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?
share|improve this answer
1  
Those numbers (LOC / day) last I knew were lower - its about 30. This is DESIGNED, CODED, DOCUMENTED and TESTED. All the superstar programmers get really offended by these numbers because they know they can throw out 1000 lines of code / day. They conveniently forget the bit about the time for design, document, test. (And time in progress meetings, foul-up fixing, sorting a broken architecture, etc - but you do actually have to count that too. Time is time.) – quickly_now Mar 12 '11 at 0:10
1  
I should add - this magic number of LOC / day seems to have remained pretty much constant over the last 30-40 years. ie 30 odd lines of assembler... 30 odd lines of FORTRAN... 30 odd lines of c#. Those lines of code might now do more, but the overall productivity rates measured in LOC/day have been fairly stubbornly unchanged for a very long time. – quickly_now Mar 12 '11 at 0:12
In my post, I said that the code would only be 50%, so you would have to double the guess. In reality, I think the code would be just ~10%, but as the program has already been designed, it shouldn't take so long (or it depends on how different the two languages are) – Anto Mar 12 '11 at 9:38
up vote 1 down vote

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.

share|improve this answer
+1 Investigation task is a good idea. Allows a much better scoping, which de-risks the exercise. The dangers of finding something nasty a few weeks in get a lot less. – quickly_now Mar 12 '11 at 0:08
up vote 1 down vote

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?
share|improve this answer
1  
There is a vast difference between "rewrite from scratch" and "port the code to another language". – user1249 Mar 12 '11 at 6:52
up vote 0 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.