I had another conversation last week with a potential client interesting in implementing measurements in their software development group.Â This conversation is so common that I thought it might be worth capturing here.Â Their current state is capturing staff time (effort) information on projects and tasks and capturing budget (cost) information through their normal budget management process.Â Their pain is that their annual budgeting cycle has been and gone again without any sensible discussion between IT and the business about the futility of the business(es) expecting everything on its wish list to get done without any regard to the capacity of the software development group.Â Why is this a repeated annual frustration?Â Because the software development group don't know their own capacity.Â Why don't the software development group know their own capacity?Â Because they don't have any information about the quantity (size) of software that they have produced in previous years for a given head count or effort hours or, logically, the quantity of software they will be able to produce next year for the same budget (or a different budget). I always recommend some sort of implementation of function points in this scenario but I am always quick to add, "or any other method of software sizing to get you started."Â I try to explain at this point that ther is no such thing as "accurate" software sizing because there is no arbitrary scale against which comparison can be made as they can for, say, metres.Â Hence, the trick to an acceptable software sizing approach is not "accuracy" but "consistency." What makes function points stand out is the tremendous body of research and usage that allows organizations like IFPUG to claim with some certainty that any set of Certified Function Point Specialists (CFPS) will produce the same result +/- 10% for function point analysis carried out on the same documentation of a project or application. Counting lines of code (LOC) is simple and a place of last resort if all other options are ruled out.Â Among the well-documented challenges with lines of code are the difficulty in getting consistent usage of code by programmers even within one company and the difficulty of making realistic comparisons (and hence summations) across different programming languages. If function points are really not feasible, an option better than LOC's is a specific internal framework based upon the structure of typical in-house problems.Â For example, browser-based projects might use counts of parameters such as pages, user inputs, etc.Â This approach can be quite effective if it is calibrated over time against actual in-house experience.Â It's limitations are that comparison and summation across different types of projects is inconsistent and comparison to external benchmark data is impossible.