[sanitycheck]

"1. Finish the last 10–20% of a project"

This isn't getting stuck, the "last 20%" of a project takes 80% of the time. This is when you start to get the REAL requirements.

[D-Coder]

Early in my career, I learned that if I wasn't sure how something was supposed to work, I needed to ask sooner rather than later, because it was unlikely to get clearer all by itself. No matter how ignorant it made me look.

[sanitycheck]

I learned that too.

Then years later I learned that asking too many questions early on that people don't know the answer to gets me a reputation of being "awkward", "negative" or "not a team player". It's not "agile" to properly understand a problem before trying to solve it, apparently!

These days I limit the early questions to ones on which fundamental architecture and technology decisions rest. My estimates incorporate an "unknown unknowns" line.

[sgtnoodle]

A lot of problems worth solving have a long tail of 9's to chase down, i.e. 99.999%

Self driving cars is one of those projects.

[thaumasiotes]

It's not so much that high-value problems have a long tail to chase down.

All problems are like that; the difference for high-value problems is that working on the tail is worth doing, because the problem is high-value.

[bpicolo]

It's when the bits that were "unknown unknowns" start to matter.

[ClumsyPilot]

exactly, usually it turns out the final 20% are actually >50%