The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(

This why you should use confidence intervals for estimates. Use a 80% confidence interval, for example. 10% of the time, you should come in under the best case estimate. 10% of the time, it should take longer than the worst case estimate.

How do you know if your estimate is good? Would you rather bet on your estimate or on hitting one of 8 numbers on a 10-number roulette wheel? If you prefer one of the bets, adjust your estimates. If you're indifferent between the bets, the estimates accurately reflect your beliefs.

(The roulette wheel is from the book, How to Measure Anything by Hubbard. Confidence interval estimates are from LiquidPlanner, https://web.archive.org/web/20120508001704/http://www.liquid...)

That’s why time limiting rather than estimating works for me. It forces me to contend with the question: “can I get this done today?” That’s usually an easier question to answer because it’s to tightly time bound. I’m not always correct but I’ll know tomorrow if I wasn’t, rather than next month!

When I’m asked on longer time frames, I’m much less confident but it’s still more concrete than the other way around.

It really depends. Anyone doing meaningful work will have hard time giving estimates. But churning up the next CRUD application with now special requirements can have no unknown variables. The question of course remains, why would anyone want to waste their time reinventing a spreadsheet.

>why would anyone want to waste their time reinventing a spreadsheet

I hope this is tongue in cheek, right? If not, here are some reasons:

1) spreadsheets embed "functions" via macros and macros are often flagged as malicious. Just combining native functions can get pretty complex.

2) in a spreadsheet, everybody sees the input, which is not always ideal

3) data types are controlled by users for the entire column or sheet, which can mess up formulas

I could probably think of additional reasons.

You are correct, comparing making the next CRUD application to reinventing the spreadsheet was supposed to be a slightly humorous way to describe the repetitive and not too challenging part of writing business applications.

There also are people who use software to guide space rockets, cars, optimise calculation algorithms and more.

My guess is people with background mostly in CRUD don't get how everybody else messes up estimating so badly and people in the innovative task group find it hard to believe sane people would waste their time giving any estimates other than for technically irrelevant business reasons.