If you don't overcomplicate your software, this problem is much less significant. If your code is easy, fixing bugs will be easy.
Why the last 20% of work takes the same amount of time as the first 80%
11–20 of 55 posts
Re: Why the last 20% of work takes the same amount of time as the first 80%
#12If you don't overcomplicate your software, this problem is much less significant. If your code is easy, fixing bugs will be easy.
Yes but then that first 80% looks much less impressive because it took a lot more time to write. When the product is finished it shows, though.
Re: Why the last 20% of work takes the same amount of time as the first 80%
#13Simple, when you said you where 80% done...you actually weren't (presuming your metric is time).
In the analogy, the metric is distance, not time. So I think the metric in the software proverb is feature-completeness.
Re: Why the last 20% of work takes the same amount of time as the first 80%
#14That's the most annoying comma I've seen in a while. :) Great article though.
The author is probably not a native speaker of English. For example: Their name doesn't sound German, but that comma makes perfect sense when you translate the sentence to German. Whatever their native language may be, it might have similar rules of comma usage.
Re: Why the last 20% of work takes the same amount of time as the first 80%
#15Lol, am I the only one who thought of Michael Douglas in "Falling Down" while reading the last paragraph?
Re: Why the last 20% of work takes the same amount of time as the first 80%
#16Simple, when you said you where 80% done...you actually weren't (presuming your metric is time).
How to measure a project's progress? If time is your metric, then the last 20% should be done in 20% of the total time. (And that's right, when the OP says she was 80% done, she actually was 50% done.) If your metric is something else, what could it be? And perhaps it is not the best metric after all: a loading progress bar that goes quickly to 80% and then slows down (by a factor of 4) until the end may not be the b…
The metric given to the client is that of time, but the metric that ends up being measured is (for lack of a better term) "visible product completion", i.e. percentage of product that 'looks' completed. If I read OP right, the last 20% that is being talked about in the article is mostly a nip here and a tuck. The overall product, from this point onwards, almost always remains largely constant.
To bring in yet another analogy, think of the project as a car being refurbished. The last 20% of work may not change much in terms of external chassis, but it is all about fine-tuning the engine, and the drivetrain. The client still sees the same car that you showed him at "80% done," except now the engine runs much better and the car purrs like a sexy, sexy kitten.
The problem, IMHO, is you can't give an accurate metric no matter how much you try.
If you give a liberal estimate and end up doing 80% of the product in 50% of the time, the client will expect you to finish the 20% in 12.5% of the original time-frame - the very 20 % that almost always takes about 80% of time. On the other hand, if you take 80% of the estimated time-frame to deliver 80% of the product, the remaining 20% will always trip you up because it almost always needs another 80% of time.
I've found that the best way to keep everyone happy is to finish 80% of the product in 50% of the time but show the client 50% of the product and spend the remaining 50% of time, finishing the 20%. It's a win-win, IMHO.
Re: Why the last 20% of work takes the same amount of time as the first 80%
#17It's easy to write a script that does one thing in exactly one way, but it's hard to build something that everyone can use.
Re: Why the last 20% of work takes the same amount of time as the first 80%
#18Home building also follows the same analogy. Our house was one of the first completed in our neighborhood, and we moved in before most of the others began construction. The foundation, framing, roofing, and siding all go up pretty quickly. As the house nears (visual) completion, the detail work and coordinating the subcontractors and inspectors stretches out the timeline.
Re: Why the last 20% of work takes the same amount of time as the first 80%
#19Wow I totally agree. And it's probably why I don't finish anything, because I am conditioned to expect it to be same work as earlier. Not just for this, but almost everything. The Paredo Time Principle?
Pareto Principle
The Pareto principle (also known as the 80–20 rule, the law of the vital few, and the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes.
Re: Why the last 20% of work takes the same amount of time as the first 80%
#20I think this is a great analogy. The reason why it works is that we tend to relate progress in one intuitive metric (distance travelled) to a less intuitive one: time. Why shouldn't 80% of the trip be done when 80% of the distance is covered? Likewise, a merely sketched-out project can look dangerously complete.
In both cases you get caught by complexity. It's easy enough to drive in a straight line for a while, and your app's login system will likely work the same as most others'. But the devil, in both the city and in your code, is in the details.