The first 90% of a project takes 90% of the time and the last 10% takes the another 200% | Hacker News Reader

The first 90% of a project takes 90% of the time and the last 10% takes the another 200%

onista.wordpress.com

I think I prefer this adage:

"the first 90 percent of the work is easy, the second 90 percent wears you down, and the last 90 percent - the attention to detail - makes a good product"

(from http://www.pacifict.com/Story/)

A friend of mine said something to me one day that really struck me - "I don't think I'm humble enough to be a programmer". He has done programming in the past, he knows what's up, and he knows that you need to put aside your ego and spend just hours figuring out one tiny bug (that ends up being something stupidly obvious in the end), days perfecting the last .1% of your project, and so on. It's humbling. Not everyone can deal with that. It's just as much of an aspect of a good coder as anything else.

You will never finish the last 10% of a project. In software you're never more than 90% done. EVER.

Not to break out the Clinton-esse, but I think that depends on your definition of "done".

But I agree, there is always room for improvement. Most dev cycles are based on milestones that have a quantified completion point, and that's when things are "done". Otherwise we'd never get anything "done". We change the language. ;)

It's just that every basket of tasks that compose a Milestone (bug fixes, UI enhancements, etc) has a statistical break down of things that tend to be really easy --> really hard. Being that a certain % of tasks on average will be really hard (say ~10%), you end up spending ~90% of your time on those ~10% of tasks. So even when you quantify things down to a completion point, you still see this (perceptionally) diminishing return on labor invested phenomenon.

When the hardware failure is more frequent than failures in your software, we can consider that "good enough" (for consumer-level applications.)

A completed website is a dead website. A completed application is a dead application. A completed open source project is a dead open source project.

There are some programs that can be both in common use and "dead." yes(1), echo(1) and the like come to mind.

I just started programming (always been the biz guy, but thought I might as well learn to hack) and I have a habit of never starting a new module before the current one works without any known bugs. This might take a bit longer, but when I'm done I'm done - and usually there are only minor bugs to be fixed.

Is this not the normal way of doing things, or am I missing something? Or is it simply because I only do simple stuff? (currently doing a website with user profiles, different sorts of to-do lists, ratings, gannt charts, a blog tool, calendar, and some ajax thrown in for the hell of it)

Where, in your experience, does this last unseen mountain of work come from? Am I about to be hit hard with something unexpected?

Yes, your approach is good and should work pretty well. However, in my academic experience, the perception of "done" can be deceptive, even for a well defined problem. The purpose of the saying is to make people wary of thinking they are done.

Similarly, it is said that the point of debugging is to find bugs, not to remove all bugs. Again, the idea is if you think you've found all the bugs, you're probably wrong.

However, you may well be one of the lucky individuals who can understand the entirity of the program in one go. And, it is good to attempt to do so, even if you usually can't. Thinking through the entire logic of my programs helps a lot as I debug.

Thanks for the feedback.

Usually coders put together a prototype and then develop the final version by either (1) fixing the prototype, or (2) developing it from scratch. When time becomes an issue, it's natural for teams to choose #1 instead of #2. But since the prototype is rarely designed with the exact use in mind (or even with things like security) that means lots of stuff to fix and design-around.

Using a good framework, keeping a sense of the long-term architecture needed and following agile/DRY practices cuts down on the difference between prototypes and final products, and is one of the reason (imho) for the popularity of Rails and the 37Signals approach to web development. Most people just flail though.

You probably need more experience. Nobody writes bug free code. Furthermore it's often not a good idea to write "perfect" code the first time around. When your code base grows, you might need to change things around and refactor some stuff.

I think the real problem in this case is being unwilling to cut features, and having too large of an initial feature set.

The last 10% always takes a long time, but it sounds like things are getting out of hand here.

Another 200% of what? The "90%" already taken? If you work on something for 90 hours, then for another 180 hours, that 90 hours was actually "the first 33%," so I guess I don't understand why he doesn't just refer to it as such. But then we wouldn't have a blog post (with wonderful the grammar).

Reply on news.ycombinator.com