Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

matvoz.com

Post reply on HN
Print view View original

31–40 of 55 posts

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

#31

Post by cclogg »

radley wrote: post #30

The saying is something like: once you're 90% done, you're halfway done. 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.

Totally. I find it's especially true for UX or animation stuff. Like you get the whole application working and then animations need to be put in, but those end up causing issues with states/transitions and smoothness, which take a long time to iron out into a nice place.

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

#32

Post by [deleted] »

bbx wrote: post #24

Love this analogy because you can extrapolate it even further. 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 fe…

[deleted]

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

#33

Post by brissmyr »

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't yet tested in production,. Even so I close my eyes, mark these task as done and move along.

So the last 20% is actually a bunch of 0.5 percenters pushed to the end of a project. At least for me.

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

#34

Post by jacques_chester »

While doing some research for an article[1] I read a paper[2] in which the main causes of underestimating are given as:

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.

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

#35

Post by barce »

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.

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

#36

Post by cam_l »

bbx wrote: post #24

Love this analogy because you can extrapolate it even further. 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 fe…

I love walking around in the city.

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

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

#37

Post by tomhebbron »

The last 20% takes time because you're in the realm of the last inch.

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

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

#38

Post by dreamfactory »

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.

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

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

#39

Post by tomhebbron »

tomhebbron wrote: post #37

The last 20% takes time because you're in the realm of the last inch. 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 te…

I should add that as a pragmatist, sometimes you have to leave the last inch - reaching perfection isn't always compatible with life in the real world :/

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

#40

Post by tomhebbron »

barce wrote: post #35

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.

An analogy is like a car. If you take it too far, it breaks down :)
Post reply on HN