Why the last 20% of work takes the same amount of time as the first 80%

Love the analogy!<p>The worst is when you finished the last 20% and get out of traffic only to discover you drove to the wrong city ;)

Love this analogy because you can extrapolate it even further.<p>I&#x27;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 &quot;I&#x27;ll visit that city later&quot;.<p>Or, quite often, halfway towards my destination (let&#x27;s say 40%), I&#x27;ll see a board saying &quot;Next exit: even better city&quot;, 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 <i>any</i> city, or even coming close to one.

The analogy is nice, but I&#x27;d enhance it a little bit to emphasize the responsibility of, ahem, driver and make all of this more useful. Unless it isn&#x27;t his first trip to the city, the driver needs to reduce his optimism about the arrival time. Especially at the beginning when he has a lot of time, he needs to avoid all those tempting things like: playing with his new GPS to design the best route; exploring the new and&#x2F;or intriguing parts of suburbia, changing the cars for fun and so long ...

That&#x27;s the most annoying comma I&#x27;ve seen in a while. :) Great article though.

Great Analogy, the basic idea is similar to this quora post (linked below) both in the travel metaphor and the fact that both deal with software development effort estimation:<p><a href="http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3" rel="nofollow">http:&#x2F;&#x2F;www.quora.com&#x2F;Engineering-Management&#x2F;Why-are-software...</a>

Simple, when you said you where 80% done...you actually weren&#x27;t (presuming your metric is time).

In 2002 Microsoft noted that by fixing the top 20% most reported bugs, 80% of the errors and crashes would be eliminated.

I think it is because people are terrible at considering hidden complexity and the odds of something unexpected happening.<p>My biz partner has a philosophy of &quot;there is no such thing as a simple app.&quot; Hidden complexity is everywhere.<p>Consider user login. A form with username and password right?<p>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?<p>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%.

In case the site isn&#x27;t loading for you (wasn&#x27;t for me):<p><a href="http://webcache.googleusercontent.com/search?q=cache:www.matvoz.com/blog/2013/10/let-me-tell-you-why-the-last-20-od-work-takes-the-same-amount-of-time-as-the-first-80/" rel="nofollow">http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:www.mat...</a>

The saying is something like: once you&#x27;re 90% done, you&#x27;re halfway done.<p>For code, it&#x27;s because you&#x27;ve solved all the easy stuff and can finally see a product. It&#x27;s the unexpected UX problems along with the dumb-but-hard-to-solve bugs you&#x27;re now handling.

While doing some research for an article[1] I read a paper[2] in which the main causes of underestimating are given as:<p>1. &quot;Frequent requests for changes&quot;.<p>2. &quot;Overlooked tasks&quot;.<p>Agile methodologies are good at placing #1 front and centre. But importing that fusty old concept, the checklist, might help a lot with #2.<p>[1] <a href="http://confidest.com/articles/how-accurate-was-that-estimate/" rel="nofollow">http:&#x2F;&#x2F;confidest.com&#x2F;articles&#x2F;how-accurate-was-that-estimate...</a><p>[2] Albert L. Lederer and Jayesh Prasad. &quot;Nine Management Guidelines for Better Cost Estimating&quot;. Transactions of the ACM. February 1992.

My Math teacher in College used to tell me it takes 5 times the effort to go from 70 to 100 marks, than it took to go from 0 to 70 marks. Finishing well is hard and often takes more than just raw application of hard work.<p>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&#x27;s wisdom and apply it to your daily craft.<p>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.<p>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.<p>For that you can only do it right if you go slow but steady.<p>Remember you either go far or fast, never both. You will have the stamina or strength to only do one of them.

Home 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.

The last 20% takes time because you&#x27;re in the realm of the last inch.<p><i>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.</i><p>From Aleksandr Solzhenitsyn&#x27;s book &quot;In the First Circle&quot;.

How is driving similar enough to coding? You can take 2 coding projects and the times for a team to complete them and their estimates will differ wildly. Commuting on the 280 to Palo Alto from San Francisco is 45 minutes on average. There is nothing mysterious about this or complicated. Coding is much harder and the OP is guilty of a bad analogy fallacy.

I knew a manager whose favorite saying was that we just needed to do the 20% of the work that got us 80% of the way there.<p>Well, needless to say, he never got a minimal viable product out there.<p>It definitely makes sense to be &quot;lean&quot; and not do anything that doesn&#x27;t need to be done, but if you&#x27;re lean you still need to complete 100% of the MVP.

This kind of fractal complexity is true per batch. The problem being described here is quite simply large batch sizes, with many projects treated even as just a single batch. The smaller your batch size, the more constant your overall project velocity is.<p>80&#x2F;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).<p>Unfortunately very few managers involved in planning get this, and as a result don&#x27;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.)

I 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&#x27;t 80% of the trip be done when 80% of the distance is covered? Likewise, a merely sketched-out project can look dangerously complete.<p>In both cases you get caught by complexity. It&#x27;s easy enough to drive in a straight line for a while, and your app&#x27;s login system will likely work the same as most others&#x27;. But the devil, in both the city and in your code, is in the details.

I agree to some extent. My hypothesis is that during a project you take a lot of shortcuts, because solving that last part of a task sometimes involves a lot of work to get everything perfect and working for every user. It could be making a responsive website work in legacy browsers, or it could be a script I know works in my dev environment but I haven&#x27;t yet tested in production,. Even so I close my eyes, mark these task as done and move along.<p>So the last 20% is actually a bunch of 0.5 percenters pushed to the end of a project. At least for me.

The obligatory quote:<p>&quot;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.&quot; — Tom Cargill, Bell Labs<p>[<a href="http://en.wikipedia.org/wiki/Ninety-ninety_rule" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ninety-ninety_rule</a>]

I believe you need to include arriving at your location and finding your directions were wrong&#x2F;GPS was out of date&#x2F;were given the wrong address, and need to re-do most of that last 20% drive again.

Great analogy.<p>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.

Wow I totally agree. And it&#x27;s probably why I don&#x27;t finish anything, because I am conditioned to expect it to be same work as earlier.<p>Not just for this, but almost everything.<p>The Paredo Time Principle?

Great analogy. This is just the thing I wanted to see. I am in that last 20% phase with my project and it really is a lot more work to get to a 100%.

It&#x27;s easy to write a script that does one thing in exactly one way, but it&#x27;s hard to build something that everyone can use.

I always thought it was because the last 20% is also 80% of the project because everyone underestimates the task by roughly 60%.

Lol, am I the only one who thought of Michael Douglas in &quot;Falling Down&quot; while reading the last paragraph?

Applies only to software programming? Maybe its the same for any life task?

Because we get bored.

If you don&#x27;t overcomplicate your software, this problem is much less significant. If your code is easy, fixing bugs will be easy.