One of the most frequent issues that arise in software development is that Development/Architect/QA/PM/UserEd reports to Test/PM/Client/Customer that the work is "done". And believe it or not, the response from the other side is "NO" it has x,y,z issues...

I often discuss this in our team meetings - what do you consider "done". The definition varies depending on your role. Let me start with development.

Development - The job of a developer is to think "deeply" about the system from a development point of view, they have to think laterally and not just be bound by the specs/design. Their role is to ensure that all their creative abilities are focused on writing world class code that meets the expectations of other roles.

For a developer to consider it "done" - the following checklist is what comes to my mind

(1) Are the requirements clear? Have they been documented in an email/doc/spreadsheet/piece of paper?
(2) Is the design clear/documented? In small teams, the developer might do the design, but its best to do this on an email/doc/spreadsheet/piece of paper. Reason: The cost of writing in ABC is <<< cost of writing in C, C++, C#.
(3) Are the coding standards/guidelines clear? If not, please ask the architect or PM. Typically there should be sample code with brief but precise instructions on how to code.
(4) Now, you are set to code. But wait - before you code - make sure you do an estimate. The estimates must be day wise. Anything longer than a day must be broken down. This enables you to review your goals on a daily basis and also helps you present the correct picture in the daily scrum calls/meetings if you have one.
(5) Now, you are really really set to code using your favourite language/IDE.
(6) Star coding, think, repeat... till you get the code done. Keep thinking about corner cases, scenarios in which code will break. If you dont have time, just mark it as @TODO in the comment so that you can come back and do it later. Think about performance from Day 1.
(7) Do unit testing. For e.g. if your system is to support 3 browsers, then please check on the one that is most used. If you have written a piece of code without UI (like a logic module) test with most common values. Throw in a corner case test for good measure.
(8) Make sure all your code is checked in correctly. If you use a tool for automated build, then make a build or force a build.
(9) Do unit testing again on the build on the server and NOT your development machine (neither your friends ) If something is broken, repeat Steps 5-9
(10) Send a release note to all concerned about the
(a) files checked in
(b) features/bug fixes in the release

Ok.. have a cup of your choicest beverage and relax! Consider it done...