How to deliver a done-done task

Question

It happens to me many times to deliver some task
Then it returns back to me to fix some 'minor' issues (or even major)
I'm monitoring my delivery quality and trying to improve it as I can

So, I'm maintaining a before-task-delivery checklist and trying to get the most out of it to enhance my overall quality/efficiency
I think I'm not alone in the jungle of task-delivery
Do you have notes, checklist, techniques or anything that helps you deliver a done-done task?

PS: I will post my before-task-delivery checklist as an answer to be evaluated

Answer 1

I keep a note which floats on my desktop with a list of tasks i need to do before i check in every bug fix or module of code. I also write tools which automate many parts of my task list so that i can automatically run sanity checks every time i am ready to check in code.

Its a good practice to iteratively improve your work process.

Answer 2

1. If I understand your question correctly, then I think you are looking for the problem where there is no problem exists. Programming tasks are iterative in nature and usually you can't get it 100% right the first time, someone somewhere will want it to be changed/tweaked/adjusted. In my experience, often a fix for some system behaviour has to be changed, or even reverted because someone changed their mind after observing it in action.

   To speed up the task delivery cycle, I usually try to shorten the delivery-to-feedback time.

2. If, however, you mean that your work contains serious regressions and/or bugs, I may be a testing issue (not enough automated regression tests, working with legacy code, etc, or combination of any of the above). Whether you can "fix" it depends on your project. Sometimes you can implement automated testing for your own code, but sometimes improvements to the overall QA cycle is needed for the whole project/organization (nightly builds, release cycles, smoke tests, separation of stable and development branches, etc).

   I suggest observing if that's just you or other people who have the problem of frequently introducing regressions, then you are likely to have an answer.

Answer 3

Please see this question about avoiding bugs before they come into production.

Answer 4

My suggestion is to consider all the different inputs and probable errors that something can have. This can be challenging especially when someone doesn't have an answer other than "What? You think someone would do that?!?!"

Requirements will likely change over time is something else to remember. Thus, you may deliver exactly what was asked but that wasn't what they really wanted. Picture sending someone a cake that they thought would be so good only to discover that while each of those things are delicious, you can't mix all that together and still have something delicious.