Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

How useful is it to measure function points?

We use function points at my new job. I've heard of function points but haven't had any training or experience... but I don't have much confidence in things that cannot be explained succinctly.

share|improve this question

closed as primarily opinion-based by MichaelT, GlenH7, Ixrec, gnat, Snowman Nov 8 '15 at 17:12

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

They are an attractive notion, but are terribly fuzzy. LOC is a better variable to tie to in my opinion. – Paul Nathan Dec 27 '10 at 22:48

Personally, I have never found an explicit answer to the question "What is a Function Point?" Without such, I'm REALLY hesitant about any estimating methodology that claims to do anything with Function Points.

The single most important part of a serious software estimation methodology is "periodic recalibration to actuals", which means you make your estimate, you write it down, and then, when the project is over, you compare your actual results to your estimate, and, if necessary, revise your estimating process. INCLUDED IN THAT is comparing your the INPUTS to your estimating process with the ACTUAL INPUTS.

If, for example, you estimate Source Lines of Code (SLOC), and go from there, you have to compare your actual delivered SLOC with your estimated SLOC, and see whether, how far, and where and why you went astray. An estimator that predicts man-hours perfectly, given an accurate and precise SLOC estimate in, is not going to do you any good if your SLOC estimates are worthless. Garbage in, garbage out. (The same thing applies to Function Points.)

If your SLOC (or Function Point) actuals match your initial estimates, then you can look at your cost actuals against your estimated costs, and adjust your estimator parameters to improve your results. General Dynamics/Fort Worth Division did this exercise, in detail, in the early 1980s, for F-16C/D software development, and then for several years would routinely bet the company bottom line on those estimates. GD/FW was GD's cash cow for quite a while, keeping the rest of the firm afloat, so they must have been doing something right.

And note that requirements and feature creep is THE ENEMY of software estimation.

(This is a later edit.) Bernd's last point deserves an answer. He asks what should be done about projects that come in early, and don't expend all their allocated man-hours.

This is just as much an estimating error as the (far more common) schedule overruns. The fact of the matter is this: if all of your projects are overrunning their schedule, your estimating folks are not doing their job.

If your estimating folks are doing everything right, and your managers are doing everything right, then you are going to have some projects come in early, along with the ones that come in late. Estimates are probabilities. Shade your estimator to eliminate schedule underruns, and you BY DEFINITION increase the probability of schedule overruns. If your management demands schedules and estimates with zero possibility of underrun, then you are going to be delivering schedules that WILL be overrun, guaranteed, and then you will start seeing demands for Death Marches, and then you start seeing resignations, and your overruns get much, much worse, as you try to recruit replacements (and the word gets out that your company is a sweatshop).

share|improve this answer

When dealing with the scope of a project, generally it is better to use a measure of Function Points rather than Lines of Code. Because software projects can have upwards of millions of LOC (including LOC in libraries) the number becomes relatively meaningless.

How do you measure LOC if you're calling functionality from libraries? Do you include LOC from libraries? If you don't include LOC from libraries, does your boss not thing you're writing enough LOC?

Generally, it is better to say "I completed XXX functionality" rather than "I wrote XXX lines of code".

But I suggest you see for yourself. Is it easier for you to estimate Function Points or Lines of Code? Plug those results into the COCOMO II model, and see which is easier to use.

Also, this COCOMO II Manual gives a detailed description of Function Points and LOC around page 11. Hopefully that's enough for you to go on.

share|improve this answer

I work in an organization where we introduced function points for calculating fixed price projects, i.e. customer and we count based on specs, agree the count and then multiply the #FP with a FP price in order to determine the project price. All this in an environment with two-digit Million Euro yearly project turnover. Intention is to remove ambiguity and negotiation from price determination which was a constant cause of friction.

We have done an initial calibration, evaluating about 2 years of project history worth two-digit Million Euro.

We clearly see that #FP and project costs correllate very indirectly. Deviations of +/- 50% are reasonably possible. However, we see (well we expect, or better: we hope) that in the long run function point counts and project costs converge.

We are now in the process of rolling this out into the organization and experience (from a suppier point of view):

  • Discussions about applications of FP counting rules. There are standards on this, however, these are subject to neglectance if one cannot argue about prices directly.

  • Client impressions that prices went up, despite the efforts we spent and are spending in calibration and calibration verification. Suspected reason is that this procedure makes costs brutally clear, no way to hide, shift or cover costs in some "don't ask" or strategic projects.

  • Need to handle projects that do not cover their costs (50% undershoot...)

share|improve this answer

They seem to be marginally useful at expressing the complexity of a given system/component, and can help managers/team leads apportion work, but they're not really any more useful than any other synthetic/arbitrary metrics (SLOC, Cyclomatic Complexity, etc.) That is, they may give an indication of the relative amount of effort required for specific parts of a system, but there's no way to map them to concrete estimates.

share|improve this answer

The use of function points in favor of lines of code seek to address several additional issues:

• The risk of "inflation" of the created lines of code, and thus reducing the value of the measurement system, if developers are incentivized to be more productive. FP advocates refer to this as measuring the size of the solution instead of the size of the problem.

• Lines of Code (LOC) measures reward low level languages because more lines of code are needed to deliver a similar amount of functionality to a higher level language. C. Jones offers a method of correcting this in his work.

• LOC measures are not useful during early project phases where estimating the number of lines of code that will be delivered is challenging. However, Function Points can be derived from requirements and therefore are useful in methods such as estimation by proxy.

share|improve this answer

Run away.

In my experience, the companies that I've seen use function points are only one step above pure madness.

share|improve this answer
This answer could be improved by explaining why function points are only one step above pure madness. – Philipp Nov 7 '15 at 13:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.