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
9 Comments
Anangrierterrarian@lemmy.blahaj.zone · 39 pts · 2y
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
subignition@kbin.social · 12 pts · 2y
Gotta get that sweet 180% time per time
aluminiumsandworm@kbin.social · 9 pts · 2y
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
Johanno@feddit.de · 4 pts · 2y
As someone who has been working on a "almost done" Task for 2 years I can confirm.
fer0n@lemm.ee · 17 pts · 2y
Not to be confused with the Pareto principle.
aksdb@feddit.de · 5 pts · 2y
I also heard (and used) it as a mix of both: "the last 20% take as long as the first 80%"
KSPAtlas@sopuli.xyz · 10 pts · 2y
I mean, it makes sense, 90% of the code is probably relatively easy while the 10% is intricate
henfredemars@infosec.pub · 2 pts · 2y
Embedded dev: basic OS functions not so bad.
Task switcher and interrupt code, short but painfully difficult to write correctly.
AVincentInSpace@pawb.social · 8 pts · 2y
it do be like dat. you thought you were almost done with this project but nooooooo