I think that is from The Mythical Man-Month, but it's been so long since I read it, I'm not sure. The thought is still valid, though, especially when applied to software estimation. Almost always, the concept of adding developers to a project late in the game is raised by non-technical managers in charge of a project when they see the schedule slipping. Many times, the manager's expected timeframe for building the software has nothing to do with the actual project and is driven by external business forces. I've seen CEO's put an idea for a new system and a request for a confirmation of their time guestimate into a single sentence. "Hey, Mike, it should only take you about three months to build a new system that automates our inventory system, right?" It can be quite a shock getting a question like this.
There are really only two ways you can respond to a statement like this:
- Capitulate and agree just to get the ball rolling. This does a disservice to the executive who now thinks he/she knows how to estimate software. Plan on getting more requests like this. You'll look like a software guru for a short period of time until you have to have your first meeting where you have to tell everybody that it's probably going to take 9 months. That's when the executive says that he meant the "office supplies" inventory, not our product inventory. It seemed like you were spending a lot of time in the shop.
- Hedge. Let the executive know that you will need to do some work to get the details of the new system down on paper before you can commit to a schedule.
Our businesses need us to provide a regimented way of analyzing projects and producing consistent estimates of project size. There have been many attempts at doing this over the years. Systems like Cocomo, sloc and various statistical methods have been developed to try to solve this problem. Most have proven to be unreliable or difficult to implement. Some, like counting lines of code, have been proven to be flat out wrong.
Probably the best method for estimating software size and effort is Function Point Counting. Function Point Counting has many laudable features including:
- Standardization of approach - there is a set of comprehensive rules that can be followed to produce consistent estimates of project size.
- It's verifiable - you can have two analysts working under a common set of assumptions come up with the same estimate.
- It's objective - you can take your finger and point to a line and say "This part of the estimate is incorrect"
- It is aware of the differences between the initial estimate of a new piece of software and estimates for changes or modifications to an existing piece of software.
- It includes a post mortem estimate so you can track how you did.
- Precision - estimation errors are handled to some degree by abstracting actual feature counts to generalizations of complexity.
- The estimate is built from the users point of view.
- It's platform independent and tunable.
- It's very time consuming - you can use a significant amount of your project budget just putting together your estimate.
- It has a pretty steep learning curve. Getting good at function point counting takes time, effort and review by others good at fp counting.
After looking at the function point method for a while, it becomes obvious that if you could increase some of the levels of abstraction that you might be able to base your estimate on use cases instead of attributes of the project. Gustav Karner proposed this concept as part of his university thesis, but I haven't been able to find his work online anywhere. A synopsis of his work can be found at http://www.bfpug.com.br/Artigos/UCP/Damodaran-Estimation_Using_Use_Case_Points.pdf.
There are some additional guidelines that we have to put into practice to consider using Use Case Point, but I'll get to that later.
I think this approach currently provides our best opportunity to produce workable estimates quickly and early in the project life-cycle.
Next: Nuts and Bolts.
Part 1: What Method to Use
Part 2: Nuts and Bolts
Part 3: Working with the Factors