Imagine it like this: When you start working on software you can write huge amounts of code in relatively short time. This new code can add huge amount of new functionality. The problem is that, often, that functionality is far from "done", there might be bugs, small changes (small in business small) and so on. So the software might feel like it is almost done (90% done), because it supports majority of the use cases. But the software still needs work. The point of this rule is that despite the software feeling like it is almost done, the amount of work to bringing that software into properly working state is as big as getting to that "almost done" state. That is because bug fixing is often time-consuming but doesn't produce lots of code.
The problem is that most developers estimate getting the software into "almost done" state, because that is relatively simple compared to actually estimating total effort the software will take.