Software Productivity Research
SPR
Home About Us Contact Us News & Refereneces
 
Training & Enablement
Software Metrics & Counsel
Benchmark & Assessment
Project Estimation
Client Services
Products Tools & Resources
Document Catalog


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: PLT2007c) 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.