Doesn't the article say that for experienced developers, the scaling factor tended to be converge on an average for each individual, even if variable for any particular task?

And Joel sidesteps the unknown-unknowns problem in that piece, by discussing boiling down tasks to <1 day chunks.

But what if you need to build a prototype before you sufficiently understand the project and options to decide on an approach? Where does that time get estimated?

The more projects I work on, the bigger of a fan of spiral development [0] I become.

Because, at root, there are 2 independent variables that drive project scheduling -- remaining work and remaining risk.

This estimation problem would drastically simplify if it allowed for "high confidence, 30 days" and "low confidence, 5 days" estimates.

And critically, that could drive different development behavior! E.g. prototype out that unknown feature where most of the remaining technical risk is.

Trying to instead boil that down to an un-risk-quantified number produces all the weird behaviors we see discussed elsewhere in the comments.

[0] https://en.m.wikipedia.org/wiki/Spiral_model