>> Selena Sol wrote:
>> I think that developer productivity is definitely true. In our projects
for
>> example, we have a 30% cost increase for any Java project even if it is
the
>> exact same application.
> Someone replied privately:
> Do you have hard numbers you can share to back up those statements? Where
> is the extra 30% going? More staff? Longer development schedules?
> Increased time-to-deploy? Costlier staff?
Well, the 30% 'is' a hard number. It is directly used by our sales force to
calculate pricing.
Most of our products are doubled up. That is, for about 90% of our product
line, we have a Perl version and a Java version. For all intents and
purposes, these are straight ports with equivalent functionality.
Given this, our sales force knows that when they sell a solution the client
will pay X dollars for a product in Perl and x + (x * .30) if they sell the
same thing in Java.
In terms of where the money is going....About 10% goes into systems
integration time, 5% goes into staff cost, 5% goes into R&D recoup, and 10%
is just thrown in there cause we know we can charge more if it is Java.
The systems integration time cost is very real with Java. Development and
implementation is at least 10% faster in Perl then it is in Java. However,
it is important to note that if a client already has a java environment set
up, then it is equally as fast to deploy in Java as it is in Perl.
> As for CPAN....I am not convinced.
>
> I find the Java libraries built in to Java to be FAR more abundant,
> integrated, and easy to use.
They're integrated into the Java environment, but how do you find
them? How do you evaluate them? Especially the for-pay libraries
that don't conform to well-known public interfaces?
Z.
