Writing good software isn't about writing software. While learning a programming language, it's easy to believe that typing or stringing together syntactic constructs or figuring out how to please a picky compiler is the single most important task you can perform, it's not. Some people even believe that programming is primarily an act of typing, once you have a problem description or a design document or a specification or a series of interconnected diagrams.
Sadly, that's not true.
Software is "done" in the sense of "usable for other people" when it has an appropriate amount of testing, when it's appropriately maintainable, when it has appropriate internal and external documentation, when it has appropriate packaging, and....
"Appropriate" here depends on a lot of circumstances, but there's the risk mentioned in the title. You have to identify what's appropriate. Will anyone else ever install the software? If so, then you need to make sure that they can. Will anyone ever have to maintain the software? Then you need to make sure that that's possible too.
It's easy to confuse "I've written the code, I just have to test it, package it, document it, clean it up, and review it, and then it'll work appropriately where you want it" for "I'm done". I like what my colleague James Shore says about Done Done; it's a good reminder that the act of writing software alone is far more than transcribing design ideas into code, or convincing a picky compiler to give you the right error message to help you fix a typo, or getting a web page to load on your development machine.
That's as important when you ask yourself if you've finished the current task as it is when someone else asks you when you'll finish.
I'm not suggesting that you lie -- far from it. I suggest instead that any estimate or prognostication or description of the completion of a project take into account the fact that you have more work to do when you save a file, even if you expect never to type another character in that file. There is no "done, except for...". There's only done.
I can't define what's "appropriate" for your project. Nor can the Perl community. Even so, the Perl community has converged on a handful of practices and mechanisms to measure and to encourage appropriateness.
You can see this principle at work when you look at the organic community standards enforced only by convention on the CPAN. CPANTS Kwalitee measures the packaging and installability of a distribution. CPAN Testers gathers information about the measurable correctness of code. Every distribution gets its own bug and request queue on rt.cpan.org.
You could do a lot worse than to adopt similar guidelines.
