Programming Languages Table
Many years ago, Capers Jones and SPR developed a function point
(FP) estimation technique called "backfiring" wherein
a table of common programming languages was produced identifying
the approximate number of logical source statements (not
to be confused with physical lines of code) of each language that
correlated roughly with a single function point. Of course, as even
novice FP counters know, there is no such thing as a single FP.
FP values come in small groups of three, four, or more, depending
on the functional type and relative complexity. So it should be
apparent that backfiring is at best theoretical.
Still, as an everyday aspect of human nature, we like to find easy
solutions to complicated problems, and let's face it FP counting
can be complicated if one does it right. Unfortunately, backfiring
never was and never will be a completely satisfying alternative
for FP counting, although it has the virtue of being superficially
easy--too easy, it turns out. Most readers miss the fact that Capers
has always been very careful to point out in his writings the high
probability of error when using backfiring values straight out of
the table.
In our consulting practice, we can observe no consistent, discrete,
definitive relationship of logical source statements to function
points that has universal application. Local development practices
and the way languages deliver functionality differently will always
make backfiring a troublesome, dangerous enterprise – especially
if the backfiring is not meticulously calibrated to local conditions.
The reason function points were invented in the first place those
many years ago at IBM was that the line of code (LOC) metric was
becoming less and less useful as a reliable, portable, apples-to-apples
software sizing metric. That was in the late 1970s. Nothing has
happened since then to make LOC more universally meaningful. In
fact, if anything the idea of a "line of code" itself
has become virtually meaningless. So, if a synthetic metric not
based on LOC were needed in the 1970s, why would anyone – anyone
– use LOC metrics today? More astonishing, though, is that
if one has faith enough in one's LOC metrics, why would one bother
to convert them to function points? That person is still just using
the LOC count by another name.
Because backfiring at its very best is an extremely high-order
estimation technique, we strongly discourage its use in virtually
every conceivable circumstance. It is especially unsuited to sizing
enhancement projects, where the correlation between new LOC and
"new" FPs, changed LOC and "changed" FPs, etc.,
simply doesn't exist consistently from coding language to coding
language. For example, "changed" functionality in FP terms
can actually require "new" LOC to deliver. Nevertheless,
people seemingly will do anything to avoid counting FPs properly.
This raises the fundamental point: if one has no desire to count,
and one has faith in one's LOC data, why bother to translate the
LOC count to FPs? (Assuming the LOC were actually counted and not
guessed at – a lot of people don't want to count anything at
all.) But that's a rhetorical question.
Makes one wonder, though, if maybe people aren't trying to hedge
in on the scientific "cachet" of function points without
really doing the work.
| |
|
Language |
|
Level |
|
Average Source
Statements Per
Function Point |
| Nevertheless, we have
had numerous inquires concerning the SPR Programming Languages
table. Those who have inquired will be happy to hear that it
is still available. |
|
1032/AF |
|
20.00 |
|
16 |
| |
1st Generation default |
|
1.00 |
|
320 |
| |
2nd
Generation default |
|
3.00 |
|
107 |
| |
3rd Generation default |
|
4.00 |
|
80 |
| |
4th
Generation default |
|
16.00 |
|
20 |
With the foregoing hazards firmly established, the
table is now available through our fee-based subscription offering.
The specific details follow.
Just remember: as with so many other things
in life, if it seems too good to be true, it probably is. Sooner
or later, real counting will need to be done.
How to Order
The Programming Languages Table continues to be available free of charge to SPR KnowledgePLAN® licensees under active maintenance. The table is provided in Adobe PDF® via email. Please request a copy via email to KnowledgePLAN@spr.com with your serial number to receive your copy.
If you do not have a current maintenance contract, you can order and download the Programming Languages Table via our online catalog. Click here to visit the catalog.
The current version of the table (catalog code: PLT2005) is available to other companies and individuals for a one-time fee of USD $125.
For more information please send email to KnowledgePLAN@spr.com or call us at 877.570.5949
(Outside North America, please call: +1.973.273.5829)
For more information please send a note to KnowledgePLAN@spr.com.
|
