software estimation

I have a piece of code written to copy files, and a lot more, to a mainframe. I have to write another piece of code, from scratch, to do the same of actions to the same set to a UNIX box. I have to estimate how long it will take to write the second piece using the first piece as my starting block. Does anyone know of any methodologies which I can say, given x lines of code, it may take me n hours? The target language is PERL, but I could substitute C/C++ at a pinch.

over 9000 hours

Thankyou. Go stick your dick in an electric socket.

The target language is PERL,
about 5 seconds.

Its like talking to my brother and expecting a sensible answer.

>>1
How long to write the code? Just come up with a time estimate for each part and sum them. Only you know how fast you code. If you want your actual working time, multiply this by at least two times.

>>5
Ask a stupid (or deliberately vague) question, expect stupid answers.

copy files
Perl
I could have written this and read the daily reading from the Book of SICP in the time it took you to make your post.

Ah, google is my friend:

A good coder (and I am not) can write 20 LOC per hour, 500 (tested) LOC per person-week. I've just written 1500 LOC (probably more, including re-factoring) and it took me about 3 weeks. I originally estimated 10 days without doing any pseudo-code. So, not bad. Should have doubled it, though.

Ah, google is my friend:

A good coder (and I am not) can write 20 LOC per hour, 500 (tested) LOC per person-week. I've just written 1500 LOC (probably more, including re-factoring) and it took me about 3 weeks. I originally estimated 10 days without doing any pseudo-code. So, not bad. Should have doubled it, though.

>>1
If you have no idea how long it'll take you, tell whoever that you need time to assess how much time it'll take. Then stop and fucking think about the problem. Once you've got an estimate of how long it'll take you either double or triple it (depending on the scope of the problem and your domain knowledge) and give that to them.

That's the trick to being a miracle worker.

>>11
None of my stuff is rocket-science. Take a set of files, copy them to another machine, do some random shit. The problems come with the "random shit' (like what compiler options will be needed, stuff to be decided by others).

I just needed a rule of thumb about producing LOC. I'll think about doubling it in future.

this is mundane shit, kids. Don't ever become a real programmer.

>>10
good coder (and I am not) can write 20 LOC per hour
Keep in mind, this is total bullshit that only applies to Sepples and such. In any decent language, you'll produce far fewer LOC. LOC is a totally fucking stupid metric for how long a given program will take to write.

>>13
Doesn't what you're saying contradict the results of most empirical experiments, who have found that LOC per hour per person tends to stay in the same order, even with vast difference in the expressiveness of the languages?

>>14
Your ``experiments'' are bullshit.

>>12
If you're keeping track of how many LOC you're producing, you're doing it wrong. Don't write code ^{to write code}. Write code to implement features.

>>14
I have never seen these experiments. Please post links if you have any. I'm basing this on my observation that over a given period of time, programmers in other languages seem to produce a lot more LOC than me, even if we accomplish similar amounts. Do the studies you mention incorporate design time?

I've seen this more places, but here's from Lutz Prechelt, "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program", 2000:
However, there is evidence (described in Section 5.7) that at least on the average the work times reported are
reasonably accurate for the script group, too: The old rule of thumb, saying the number of lines written per
hour is independent of the language, holds fairly well across all languages.
There's exceptions of course, he mentions assembly language and APL as extreme examples.

I'm basing this on my observation that over a given period of time, programmers in other languages seem to produce a lot more LOC than me,
Not a valid comparison. There's too much variance between programmers to make that observation useful.

Anyway, you should have read this before when you followed the sources given in http://norvig.com/java-lisp.html
Are you all going senile?

There should be something out there about bugs/LOC being similar across languages too, again with extreme outliers.

[quote]I have a piece of code written to copy files, and a lot more[/quote]
What are you copying that's not files?

>>19
Sorry, badly constructed english. I copy the files, then run stuff like other scripts for compiling etc etc. Then copy the results back.

>>17
Balmer has a rant about IBM concerning this. I just want to do a test, seeing as I already have code which does a similar thing but I can't re-use it the new domain.

Actually, the total LOC *tested* hides the fact that you probably write about 4 times more than what you produce. My way of working is to constantly rework my solution until someone tells me to stop, or it looks finished. As I write, I find bugs, I rewrite, I think of neat solutions, rewrite. Even with all this re-writing, the metric I found on the net resembled my work-rate very neatly. I tend to write docs and tests as well, as well as multi-task support tasks, so maybe I'm not so bad after all :-)

>>20
⚑ Please don't respond toBBCODEfailures! ⚑