The worst is when you finished the last 20% and get out of traffic only to discover you drove to the wrong city ;)
I'm the kind of guy that travels the first 80% on the highway, reaches the traffic-bloated city, and actually makes a U-turn to head towards a totally new city, thinking "I'll visit that city later".
Or, quite often, halfway towards my destination (let's say 40%), I'll see a board saying "Next exit: even better city", and take that exit. After taking a few of these exits, I will have spent hours or even days on the highway, without having reached any city, or even coming close to one.
But by the time I get there I find all my money has been spent (fee) on transport, and I have to choose between window shopping (unpaid work) or jumping on another bus (client) and hope it goes past my original destination..
http://www.quora.com/Engineering-Management/Why-are-software...
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 best progress bar after all.
I guess that the difficulty is to get a precise idea of the time you need to finish something.
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.
My biz partner has a philosophy of "there is no such thing as a simple app." Hidden complexity is everywhere.
Consider user login. A form with username and password right?
Do you show the password as they type it or obfuscate it? What if the user forgets username or password? How do you handle password reset? Did you make sure you are sending over https? What about captcha? Do you use one at all? Do you have password strength requirements? How do you want to store the password data? What about security questions? What about error handling? Do you support oauth like facebook login? Will this work for login via api? How are you going to test login? Will you write feature specs, unit tests, etc?
Now, how often do people think through features in that kind of detail when estimating? Look at the above questions. All of a sudden the last 20% starts to look like 80%.
http://webcache.googleusercontent.com/search?q=cache:www.mat...
For code, it's because you've solved all the easy stuff and can finally see a product. It's the unexpected UX problems along with the dumb-but-hard-to-solve bugs you're now handling.
1. "Frequent requests for changes".
2. "Overlooked tasks".
Agile methodologies are good at placing #1 front and centre. But importing that fusty old concept, the checklist, might help a lot with #2.
[1] http://confidest.com/articles/how-accurate-was-that-estimate...
[2] Albert L. Lederer and Jayesh Prasad. "Nine Management Guidelines for Better Cost Estimating". Transactions of the ACM. February 1992.
To get it really ~100% percent right, you need to not only work hard, or work more but you need to develop a strange obsession for quality. And that only comes from continual reading, and upgrading your skills. To constantly learn from experience and other people's wisdom and apply it to your daily craft.
Getting to the 80% done part, if you note you will be often working on stuff which is largely solved and rewritten many times. Things like working with DB or a file, or parsing an XML- Basically stuff like that is what constitutes first 80% of the project. The remaining 20% is what your actual project is, its functional requirements, its quality and other stuff like that.
This is not just with software, building a home is very similar. It takes very little time to build the frame structure(walls, foundation, roof etc)- A lot more time to actually finish the home which is livable.
For that you can only do it right if you go slow but steady.
Remember you either go far or fast, never both. You will have the stamina or strength to only do one of them.
Now listen to the rule of the last inch. The realm of the last inch. The job is almost finished, the goal almost attained, everything possible seems to have been achieved, every difficulty overcome — and yet the quality is just not there. The work needs more finish, perhaps further research. In that moment of weariness and self-satisfaction, the temptation is greatest to give up, not to strive for the peak of quality. That’s the realm of the last inch — here, the work is very, very complex, but it’s also particularly valuable because it’s done with the most perfect means. The rule of the last inch is simply this — not to leave it undone. And not to put it off — because otherwise your mind loses touch with that realm. And not to mind how much time you spend on it, because the aim is not to finish the job quickly, but to reach perfection.
From Aleksandr Solzhenitsyn's book "In the First Circle".
Well, needless to say, he never got a minimal viable product out there.
It definitely makes sense to be "lean" and not do anything that doesn't need to be done, but if you're lean you still need to complete 100% of the MVP.
80/20 is therefore a sign of a poorly managed project (since visibility of true velocity is hidden, planning is impossible at best or based on false data at worst, and overruns are collected and unpacked only at the end).
Unfortunately very few managers involved in planning get this, and as a result don't recognise their responsibility is for delivering the whole at a predictable rate by managing this process. (Instead we often see a sick project management culture of not giving the client what they need and whipping the delivery horses harder, under the illusion that this is just how projects get delivered - always painfully and late, if at all.)
A great read on the subject of batch sizes and limiting WIP: http://www.amazon.com/The-Principles-Product-Development-Flo...
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.
So the last 20% is actually a bunch of 0.5 percenters pushed to the end of a project. At least for me.
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." — Tom Cargill, Bell Labs
I think next time if we try to guess the amount of time we need to complete a project, we will just ask how long would it take to complete up to Stage 80%. And just times it by two.
Not just for this, but almost everything.
The Paredo Time 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.
That is a very clever approach. I don't think I've ever heard of that before. I'll have to give it a try.