oh, no, it's far worse than that. the last 90% is enough time to make what you thought was the first 90% become 10%.
so 0.9*expected time = 0.1* actual time
which, if you can do some very basic algebra, results in 900%. this implies that every project will seem "almost done" for about 9x the length of time you thought the project would take. in my experience, this is roughly correct
oooh thats my code never works
i forgot to time travel to spend 90% of my time doing the last 10% of code. i get it now
Gotta get that sweet 180% time per time
oh, no, it's far worse than that. the last 90% is enough time to make what you thought was the first 90% become 10%.
so 0.9*expected time = 0.1* actual time
which, if you can do some very basic algebra, results in 900%. this implies that every project will seem "almost done" for about 9x the length of time you thought the project would take. in my experience, this is roughly correct
As someone who has been working on a "almost done" Task for 2 years I can confirm.
Not to be confused with the Pareto principle.
I also heard (and used) it as a mix of both: "the last 20% take as long as the first 80%"
I mean, it makes sense, 90% of the code is probably relatively easy while the 10% is intricate
Embedded dev: basic OS functions not so bad.
Task switcher and interrupt code, short but painfully difficult to write correctly.
it do be like dat. you thought you were almost done with this project but nooooooo