Re^6: Code Statements/Lines per Function Point

Thank you dragonchild,
I see your point. Yet I do not really want to compare Perl against any other language. I just would like to use my new understanding of software engineering and reviewing of code and productivity to get a hang about my own abilities and much more so even be able to estimate the cost of future developments in a slightly better way. As fas as now I use to build a very detailed framework of code on my mind and then calculating down that the average slightly complicated Regexp costs me 10 minutes, opening a file and reading it costs me 1.5, ...
The problem is that as soon as I decide to use slightly different objects, define a different output file type for convenience, ... The additional time required might be affected by this. So I try to find a more general approach, that does not force me to sit down for two hours and basically plan how to write a program that takes me two weeks time when considering the cost, as this very fast approach normally does.
Yet I would like to be able to estimate how the effort of a line of Delphi/Pascal code relates to Perl. I think it is true that the line number cannot be considered so the operations approach seems to be very reasonable and also produces a compareable value.

Cheers,
PerlingTheUK

Comment on Re^6: Code Statements/Lines per Function Point

Replies are listed 'Best First'.
Re^7: Code Statements/Lines per Function Point by dragonchild (Archbishop) on Aug 25, 2004 at 14:32 UTC
I think the issue you're trying to grasp at is how long does it take to implement a given specification in a given language. Function-points (which I just learned about ... thank you!) are probably the sanest (if very complex) way of describing the cost of the specification in a language-agnostic fashion. The problem is that the cost for a given language depends a great deal on many factors, some of which could be: The expressiveness of the language The amount of book-keeping the language provides for you The expected performance of the result The skill of the programmer(s), both in terms of the best and the average The size of the team (bigger is not always better!) The expected maintainers The allowed usage of outside modules The architecture decisions that have already been made Any current codebase and how easy/safe it is to make modifications to it For example, I might be tasked with building a web application from scratch. I am told to do what needs done to make it happen. So, I pick Apache, mod_perl, Perl 5.8.x, and use whatever CPAN modules are necessary to make it happen. But, if I was told I had to use Java, Oracle's AppServer, and I had to interface with existing code, the amount of time it takes goes up dramatically, even though I am handed what seems like half the project on a silver platter. Both of those assume a single developer. What if I had to interface with three teams, one of which is at a different location, and coordinate between two departments? What if I had to use more than one language? What I'm getting at is that the cost of a project very rarely depends mostly on the choice of language. In fact, the choice of language may account for less than 10% of the cost of a project. Now, one should minimize as many costs as possible, so choosing the right language for the task (which may not always be Perl) is a good goal. However, focusing on it may be premature optimization. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]

Replies are listed 'Best First'.

Re^7: Code Statements/Lines per Function Point
by dragonchild (Archbishop) on Aug 25, 2004 at 14:32 UTC

The problem is that the cost for a given language depends a great deal on many factors, some of which could be:

The expressiveness of the language
The amount of book-keeping the language provides for you
The expected performance of the result
The skill of the programmer(s), both in terms of the best and the average
The size of the team (bigger is not always better!)
The expected maintainers
The allowed usage of outside modules
The architecture decisions that have already been made
Any current codebase and how easy/safe it is to make modifications to it

For example, I might be tasked with building a web application from scratch. I am told to do what needs done to make it happen. So, I pick Apache, mod_perl, Perl 5.8.x, and use whatever CPAN modules are necessary to make it happen.

But, if I was told I had to use Java, Oracle's AppServer, and I had to interface with existing code, the amount of time it takes goes up dramatically, even though I am handed what seems like half the project on a silver platter.

Both of those assume a single developer. What if I had to interface with three teams, one of which is at a different location, and coordinate between two departments? What if I had to use more than one language?

What I'm getting at is that the cost of a project very rarely depends mostly on the choice of language. In fact, the choice of language may account for less than 10% of the cost of a project. Now, one should minimize as many costs as possible, so choosing the right language for the task (which may not always be Perl) is a good goal. However, focusing on it may be premature optimization.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]