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