A personal rule of thumb I derived from the ninety-ninety rule is this: "Before starting a project, ask yourself if you would still do it if you knew it would cost twice as much and take twice as long as you expect. Because it probably will."

I totally agree. I tend to phrase it a bit differently: "If you need to know how long it will take before deciding if it is important enough, then it is likely not important enough."

Another kind of corollary: "If the business will go under if we don't get this done by X, then we probably need a new business plan, not faster development".

These are rules of thumb and there are definite places where they don't hold, but I've found it genuinely useful to consider when the inevitable tough questions start to get asked.

Twice is a (reasonable) minimum.

I see the 90% rule as a recursive function: First we get 90% of the whole work in the first iteration, then 90% of the remaining code (now we are 99% complete), then 99.9% and so on.

The iteration is stopped when the software has enough features and an acceptable level of bugs to be considered complete. What complete is depends entirely on the field of the software. For a proof of concept software we can stop after the first iteration, but for a safety critical software we might need 3, 4, or even more itarions.

I like this, it rings true in my experience.

I've found that under-promising and over-delivering requires me to quadruple my best estimate.

Unfortunately, lots of us bid against people who over-promise. By the time the project is obviously behind schedule, it's too late, and the client can't switch to someone else.

To be honest from my experience usually it’s a factor of five to get to full completion.

Sounds like you're just rounding up from 99.999%.

True! I came up with the factor five by observation but it’s in line with the predictions

Note that this isn't a joke: https://en.wikipedia.org/wiki/Ninety-ninety_rule

That's funnier. As stated in the post, it's really just the Pareto principle again.