Every once in a while, someone will ask about the value of incorporating function points. For those under, say, the age of 40, function points were something that were devised in the late 1970s in order to come up with a consistent metric for estimating the size of a software system.

Sure, function points can end up being fairly accurate from time to time. They may help in terms of comparing efforts on two software projects.

The problem is the investment required to derive function points. Function point analysis is expensive (albeit there have been several initiatives to try and simplify the effort). In order to be useful across projects, a metric has to be consistently calculated. In the case of function points, consistently calculating them is a meticulous effort. Generally, you need an "expert" in order to do well with function points.

Fortunately, to save the day, we have high-priced consultants that can come in and explain why (a) agile sucks and (b) why they are the one who can do these ridiculous calculations.

Horse hockey. I've seen as good or better results from agile estimating and planning techniques. Or, agile aside, from notions that are much simpler to calculate ("how many screens are there?"). These techniques, which come more cheaply, are far less onerous, and anybody can quickly learn how to do them without hiring an overpriced consultant (or "software economist").

Should you trust me, a "high-priced consultant" myself to tell you function points are dead? Look around. There's a good reason why most organizations have moved off of such heavyweight nonsense. All of these wondrous efforts and calculations make managers and executives feel good. Function points look like a lot of effort went into them, and fancy looking calculations back this effort up. But that's about it. They don't really add value to a project. What adds value is getting quality product in front of a customer on a consistent basis, giving them what they ask for and expect.

A good consultant will teach you how to start solving your own problems. A questionable one will sell you complexity you don't need.

posted by Jeff L.  # 11/09/2007 02:23:00 PM Database TDD Blogs