We all have problems estimating the effort and time required to build a software systems product. The authors did an open survey of present methods and conclude that we are seeking precision in the estimates that belie the accuracy of the estimation parameters. Such estimates create mistrust. Their most important conclusion is that whenever the feature list changes, the estimates must be redone. In addition, I advocate that the estimates be redone at the end each phase of the development of a release or increment.

The implication in this paper is that professional software estimators are required to make reasonable estimates. The need to take into account the feedback estimators’ impact on the underlying project must be accounted for.

These conclusions are based on survey data using a Web-based questionnaire. It is surprising that the authors derived meaningful insights from the Web survey data even though there was no professional human estimator helping the contributors complete the survey. It was disappointing to see no use of algorithmic estimation from Boehm’s work or Putnam’s schedule compression approach.

A strong conclusion, restated several times, is that, “change requests cannot be seen as reason(s) for inaccurate estimates as (the changes must) ... lead to re-estimation.”

Sections F and G provide crisp insights into the software estimation problem and the need to have frequent re-estimations without unnatural controls. The conclusions provide tips for practitioners including:

1. Bosses need to understand that restricting estimates leads to overruns.

2. Job evaluation of estimators should include the accuracy of their estimates.

3. Change request re-estimation “is a custom more honor’d in the breach than the observance” (Hamlet, Act 1, Scene 4).