The importance of estimation!

An article on the importance of lines of code caught my eye the other day (Why is it useful to count the number of Lines Of Code (LOC) ?). I personally feel that the use of lines of code for estimation has several issues.

• Complex loops in code vs form code, it is possible to have a few complex lines of code in a loop and lots of code for generating a form. Verifying and fixing a bug in the loop may take a long time, while a fix in form code may take very little time


• What do you do about auto generated code produced by wizards? I would like to think that the code will always work so do you need to include this in the calculation. But, will generated code always work in the context of the surrounding hand crafted code


• What about abstracted definitions. For example in Altio much of the logic and screen definition is implemented as XML definitions and executed by the internal engine. The same is true for Adobe Flex and many other RIA development tools.
  

My preference, and idealistic, approach is to use a combination of several estimation techniques. Use Function Point Analysis (FPA) to determine the high level estimate (this works well for abstracted definitions). The FPA can then be used to generate an equivelant Lines of Code (LOC) estimation, this would be determined by relating the abstract definition to the equivalent Java code or C++ code (or any other language, users choice). Finally the LOC can be used in a structured estimation platform such as COCOMO which allows you to define the complexity of the system to produce and estimated cost and duration, finally confirm this all using Triangulation Estimation. I never seem to have time to do all of this and so feel the approach is best kept for large projects, or ones where you don't want a lot of explaining to do at the end of the project when it's late.

In my experience the Agile technique of using expert judgement and Triangulation Estimation will work OK. Well let's face it you get a pretty good 99% accuracy for the number of days effort to deliver.

In my opinion, however you perform estimation is a matter of choice, the important thing is to record the results learn from them and apply past experience to new estimates. Unless you purchase the software off the shelf or use past code and modules you will always be in new and uncharted territory, so how can you accurately estimate the distance you have to go to get where you want to be. Plus, users will always move the goal post making the original estimate nonsense!


Books by Steve McConnell
I've never read the book Software Estimation: Demystifying the Black Art but I have read Steve McConnell's other books Radpid Development and Code Complete both excellent books, and so assume Software Estimation will be equally as good.