Estimates are important. Get it right and you can deliver at regular intervals. Get it wrong and you’ll languish it “when is that going to be done?” land. Software engineers are notoriously terrible at estimates.
Recently, I sold my house. One thing that stood out to me during the appraisal process was that the appraiser looked at three different methods to determine the value of our new house. One was based on comparable sales in the area. The idea being that you might determine market value of one house by guesstimating based on other similar sales. Another method looked at cost: what would it take to build a house like this? A third way looked at potential income production. In other words, if one were to rent this house, how much might one take in?
In our appraisal, the appraiser detailed which approaches he used. He explained why one should be given more weight, and he decided against developing the income method at all.
I was thinking about a recent project and how, in hindsight, it was incredibly complex. There are a dozen or so “major” features of the application. This feature touched on about five of those. Had I been thinking in those terms, I would have estimated it to be much more complex.
Software engineers ought to consider an estimating strategy more like appraisers. Use whatever black magic you might normally use. Then switch gears. Try the estimate again by another metric. And another. Different perspectives on the same problem may give you pause before declaring a feature to be easy or hard to complete.