by Arlene Minkiewicz
| September 18, 2014
Software cost estimation is hard. I have learned this the hard way – as a software developer and later as the manager of software development projects. Today, as a builder of cost estimating software, I learn something everyday about software development that reinforces the fact that software cost estimation is hard.
I attend a lot of trade shows and I talk to a lot of software people about how they estimate software costs. Many of them have no formal process, many don’t collect data as projects progress, many of them perform estimates off the cuff, and many of them, not surprisingly, are unhappy about the outcome of their software development projects.
Many of these same people are quick to point out, when presented with possible help in the form of TruePlanning for Software, why it will never work for them. Nine times out of ten, the reason they give me has to do with the uniqueness of their product, their customer base, their market or their software development process. They question the data behind the model and suggest that this data can not be successfully translated to properly model their specific situation.
And I can’t fight the uniqueness argument – it’s most likely true. Every software project has factors that make it different from all the other software projects that have occurred in the past. No two software projects are the same. I can however argue about the suitability of the data behind my model. The majority of software projects are not defined by their uniqueness. There is much more about most projects that is similar to other projects than is different. A good software estimation tool like TruePlanning for Software capitalizes on this fact by allowing the user to take advantage of industry or organizational data for those many places where a project is not unique. Further, it offers expert systems like guidance to transcend those areas where a software project veers from commonplace to extraordinary.
In software, as in life, we tend to put the most focus on the parts of a project that are challenging and interesting with much less focus on the parts that are ordinary. If, in doing this, we are discounting the lessons we can learn from history, we are doing ourselves and our software projects a disservice.