This seems like as good an opportunity as any to start a discussion: what do people think about these software cost estimation models and tools? They seem like

This seems like as good an opportunity as any to start a discussion: what do people think about these software cost estimation models and tools? They seem like a valuable tool for communicating the value of working software to non-technical businesspeople, but any programmer knows that the value, complexity, or cost to reproduce software is a function of much more than SLOC count. For instance, the SLOCCount tools use the COCOMO model (http://www.dwheeler.com/sloccount/sloccount.html#cocomo http://www.dwheeler.com/sloccount/sloccount.html#cocomo), whose follow-on COCOMO II is discussed here (http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html). These models use factors like the following to calculate an exponent which is applied to the SLOC count to estimate cost to produce: Required software reliability Database size Product complexity Execution time constraint Main storage constraint Virtual machine (HW and OS) volatility Computer turnaround time Analyst capability Applications experience Programmer capability Virtual machine experience Programming language experience Use of "modern" programming practices (e.g. structured programming) Use of software tools Required development schedule Are these the right factors? How are they suited to estimating the cost to produce or reproduce a piece of software? What would you add? It seems like some measure of the cyclomatic complexity of a codebase, or the number of syntactic elements, might add some information to the raw SLOC count. Arguably this doesn't tell you much about how much it might cost somebody to reimplement it (since that person might come up with an easier-to-code-and-maintain variant with lower cyclomatic complexity or in a more powerful language), but it might help estimate the cost to get it working in the first place.