Ask HN: Why is the last 10% always so hard? | Hacker News Reader

Ask HN: Why is the last 10% always so hard?

20 pointsIgorPartola30 comments

I am working on a small side project that I am hoping to finish soon. I did 90% of the work: set up the infrastructure, wrote all the code, made it all work end to end. What's left is to polish it all and release, but I find it harder and harder to get motivated to do it. Has this ever happened to you and how did you get through it?

View on HN

One possibility is that your 90% is an overestimate, and that there is still more work to do than you consciously admit.

"Coding, for a counterexample, is '90 percent finished' for half of the total coding time. Debugging is '99 percent complete' most of the time. 'Planning complete' is an event one can proclaim almost at will." -Mythical Man Month, page 154

I will order that book now. :)

Highly recommended.

I am pretty good about this. For most of my projects I keep a pretty atomic TODO list and move things into a DONE category whenever it's finished. The list grows as I come up with new things, and shrinks each time I get something done. I know I approach the finish line when I stop adding things to the list as quickly as I'm getting them off the list. This of course has nothing to do with the number of hours left, just the number of tasks.

Yes, my thoughts exactly.

My friend, you've just completed 10-30% of your work.

You now have infrastructure, support, updates, marketing, sales, pricing, subscription systems, and competition to deal with. (to name a few)

Creating the product is step 1.

Or you left the hardest part for the end. The hardest here does't necessarily mean the most difficult to figure out, it means the hardest for you -- the one you are least motivated to work on.

It could be the most boring or the least interesting. It could be lots of UI tweaks, or adding a feature you are just not very excited about. Objectively you know it should be a 4 week job, but unconsciously you drag the time along because you just seem unmotivated by your work. Conversely, the first 90% goes fast because you are motivated and put a lot more mental effort and time into.

My current rule of thumb is that if I don't think that I'm 90% done when I'm only 50% of the way through my schedule I'm going to miss my deadline.

My suspicion about the cause of this is that I'm conflating 'easy' with 'doesn't take long'. I think there may be some other factors to do with not wanting to admit I'll break stuff when tidying code (so not allowing time to fix it) and somehow assuming that all the little niggles that only take a couple of hours to fix will all be fixed in the same couple of hours.

The question rather vacuously implies he's over-estimating if by "10%" he means "10% of the time required"

I would think that the "10%" instead has to be some rough of the length of documents, the number of bugs, the number of features or some something similar. Overestimating still might be involved but there you have something to explain.

If you're a typical geek and into the coding and "setting up technology" aspects of a project, it's natural that adding the shine, doing design tweaks, thinking about marketing, and the "soft" elements is going to be less fun and, therefore, "harder."

I suspect if you took a print designer who was asked to design and then code a Web site, they'd spend a ton of time on the design and enjoy it, but then find the "10%" of time taken to try and turn it into HTML and upload it someplace would be similarly difficult.

Exactly.

Polishing takes time, because it's similar to design: You spent hours trying how different options look or ensuring that the use flow is flawless. There are lots of front-end coders who consider this as the fun part, they like making things look good.

People enjoying backend programming doesn't realize this, they just think that it is the trivial part of the programming (and thus requiring a little amount of time), although totally different skills are needed.

Also, many UI libraries are very cumbersome for this kind of microtweaking. CSS is very good for it, but you still encounter lots of problems when you try to make just small change.

Back when I took probabilistic combinatorics with Richard Karp, he discussed the "coupon collector problem": How long does it take someone to collect all twenty of a set of coupons, each of which appears randomly in a daily newspaper. It turns out that to get the last ones takes a good percentage of your time, since as you collect coupons, the chances of getting one that is new-to-you goes down. I think the structure of a lot of tasks has a similar diminishing returns quality. You happen to find some ingredients but getting every piece is going to be inherently harder (aside from any other factors you could name).

When you're coding, progress is immediately rewarded by a mechanism in the brain that releases pleasurable chemicals whenever you hit a milestone. It's like playing Diablo II and hearing that "ding" when you level up. (At least, this is the case for me. Especially when writing new features or refactoring.)

But the reward system for the other work (release) isn't built into your brain yet. You can trudge through it, or you can try to hack together a reward system for your brain until it's burned into place. You can promise yourself that when you ship, you'll go out to a fancy dinner, buy a video game, or go to the beach. If you have a spouse / significant other, you can ask them to take you out to dinner if you ship (this is, in my opinion, one of the best perks of not being single).

Your brain isn't a bulging mass of sheer willpower, although it's pleasant to pretend it is. You've got to figure out a way to get yourself to do the things that you want yourself to do, as much as that sounds like it doesn't make sense.

http://en.wikipedia.org/wiki/Ninety-ninety_rule

Ya, the last 10% is where 50% of the work is actually done. That is the polishing. What you think is 90% is on paper only. In reality, there is more to be done..

I've faced this situation before and still face it with my side-projects (most recently with http://weekis.com). I've realized something simple though. The last 10% got difficult because I took up 110% of work. As you progress through a project, you'll be tempted to add more features. The features may be small, but they still alter and prolong the course. Do less, work in iterations, and you'll be able to easily get past that last 10%.

What I do to overcome that is to severely reduce the scope of version 1 and to push out releases (even private ones).

This works for client work and for my own projects, too.

Having a usable something pushed out completely change the remaining part, based on feedback.

To cut your scope and try to keep a very small part of it, you can use the following techniques:

- http://www.mountaingoatsoftware.com/tools/theme-screening

- http://www.mountaingoatsoftware.com/tools/theme-scoring

- http://www.scrumalliance.org/resource_download/284 [pdf] -> most recommended

Another tip: try to find how handling the "polish/release/promote" bits could be fun for you. For me it was: learning a bit more of css/sass, monitoring the effect of promotion etc. There's almost always a way to do it in a fun fashion.

I'm exactly in this position myself. I'm 80%-90% done with a product but there's the last things that needs to be finished before I can launch, like configuration, setup procedures, small details etc.

I find it extremely hard to finish it. In my case I think it's simply because all the juicy problems have already been solved. It's darn boring coding when you need exactly what needs to be done, but you still need to do it.

A couple of tricks that worked pretty well for me. Change enviroment, if you work somewhere "fun" like a café or other public place that might give a much needed boost to finish it. Listen to interesting stuff while working, like podcasts and audio books. Visualize your product being done and all the positive things that will lead too in order to get some motiviation

I think that usually when people say that 10% of the work take disproportionally longer than they expect, it's because they're measuring the wrong thing. If you find coding easy, then writing 90% of the code doesn't equate to 90% of the work. Polish is very hard, and in most cases it isn't 10% of the work, it's more likely something about half the work. After all, that's exactly what distinguishes your product and makes it worth using. Not sure if thinking about it that way makes it feel better, but at least for planning purposes, consider calling the polish phase 50% of the work.

If it is user oriented, I would release the project and make sure you have a feedback loop to see how the project is being used by the end users. You are finished when they are happily using your project, you usually don't get to decide for them. If the project is presentation oriented, or if you only think you get one shot, then I usually step away, come back, make a punch list, and complete the project by completing the punch list.

You may be afraid to ship, and the excuses are running out.

That 10% is the difference between a hobby and a product.

I don't think the last part is hard in the sense that there's a lot of work to be done. You've stated so yourself, "what's left is to polish it all and release".

I think there's a subconscious fear of something else that you need to get over. My guess is it's possibly a fear of rejection and/or failure once you do release it.

My only suggestion is to get over that fear and like the Nike commercials say, "JUST DO IT!"

Good luck!

For me, it's because most of the puzzle has been solved which just leaves grunt work. I hate grunt work. For web projects at least, it's like building bridges--you meet in the middle--and the other guys speak a different language. It's always off by an inch or two.

I have run into this problem before. I find the best way to get motivated is to send it out to a few friends. Usually they look over it and tell me it's awesome, which is a great inspiration towards getting it out to that general audience.

There's a saying in project management: "The first 90% of the work takes the first 90% of the time. And the last 10% of the work takes the next 90% of the time".

It just feels like the last 10%. The first 90% was actually the first 50%. It just felt like 90% because it came in big chunks.

Why is the easiest 90% so easy?

The first 90% was new stuff, where I got to play with new tech (new to me that is) and different constraints. What's left is the stuff I have done many times before. Also the last part involves a lot of UI work which can get tedious.

And that, sir, is your answer. As far as the enthusiastic part of you is concerned, the problem is solved. It's like doing math in early high school -- you've already figured the thing out, but now you have to transcribe your method to the appropriate format and attend to the stupid details that will get you full marks for "showing your work" when you hand in your homework sheet (or notebook or what have you). Nobody who actually liked math for its own sake ever liked doing that crap -- I know I never did, and it wound up being the main reason I had for dropping out of school. And that same attitude is still with me, and still something I have to put a lot of effort into overcoming -- "dropping out" before the payoff really isn't an option for an adult. So yeah, it's tedious, "unnecessarily" detailed and completely uninteresting, but somebody's got to do it -- and waiting for a volunteer to drop by probably isn't going to work. Close your eyes, hold your nose, and swallow your medicine as quickly as you can -- you don't want to spend too much time tasting it.

Reply on news.ycombinator.com