We have been suffering a lot recently with an off-shore development company to whom we have sub-contracted our Flash development work. The struggle was when they say the tasks are DONE, and reviewing their "so called DONE" tasks always surprises us with the half-done and half-tested code. We have shed our blood to mentor them on what to do. As a result, they added an extra care and effort, only to defend that the 60% completed is equal to 100% completed. Cool ha? Realistically, they did not know the meaning of DONE.
Many used to say, This issue is RESOLVED, but need to check the impacted areas; This code is 100% DONE, but it has to be tested; FINISHED the user story, but UI is pending; I have COMPLETED the task, but...; and much more to convey that they have finished the assigned task. Verifying this would only let you taste the surprise since you will witness the half-baked solutions or deliveries which are extremely useless (ie, 'done' followed by 'but' = incomplete). This has become a common habit now in the industry and dilutes the real meaning of DONE. In other words, DONE has simply lost it's identity.
It is quite interesting to know, why we do this. The reasons maybe,
Lack of experience (Thinking that the task has been completed, without knowing what is left).
Lack of planning (Skipping the checklist to finish the tasks due to the time pressure).
Showing off (To prove that they can finish faster).
Lack of confidence (Taking short cuts to keep the job).
Over confidence (as time flies, the steps are skipped in the process).
Ill attitude (No passion, doing work for a sake, does not care about what is being delivered).
or Simply they have no clue on what they are doing.
Whatever maybe the reason, as a result, we end up delivering a half-understood, half-coded, half-tested and half-documented solution which will only question the reason for our existence as a professional. Hence, before saying "I am DONE" it is important to know whether you are really eligible to say it or not. So, what DONE really means?
There were times, we used to release software to production in the middle of the week and wait to fire fight the issues over the weekend. If no issues are reported for a week, we call it as a successful release. Is this known as DONE? or feeling confident about the release even before it was released. Is this called DONE? or does it mean when...
All code has been reviewed and checked in? All ATs have been validated, bugs found and reported? The client has approved the features? The product is LIVE? All features are documented?
Actually, DONE simply means that at the end of any task it has been completed with no leftovers, no dependencies and simply the task will never come back to us or we do not have to work on that again. The task could be anything like requirement gathering, development, testing, R & D, communication, prototyping, deployment, documentation or even writing an email. There are different roles and responsibilities in an organization. DONE at every level will mean differently.
When a Developer says that a feature is DONE, he mostly means, that all the features are implemented and the feature is ready for further enhancement, refactoring and thorough testing.
When a QA tells that it is DONE, he means, that the features have been tested, bugs reported in bugtracker, tested the resolved bugs, handed over to UAT.
When a Customer/Manager hears DONE, he mostly expects that the product is ready to be released to production.
So, it is obvious that the meaning of DONE varies on a case by case basis and at a different level. Not only at a role level, also varies at an organisation level. Every professional is unique, they have different experiences and see the software development from different angles. This diversity can lead to have a half-tested, half-documented, half-optimized and eventually half-ready components for the release. Which results in a poor quality in the end product. Hence, there is a real necessary to define what DONE really means to the whole organisation with a checklist to follow. Say for example,
Developers should consider things DONE only when...
requirements are understood; analysed; suggested options to implement the best and improved usability; doubts clarified; tasks split in detail; estimated; unit tests written; coded; integrated; migration done; required languages supported; code reviewed; cross browser supported; unit tested; reviewed all the acceptance criteria for all scenarios; installation/uninstallation scripts written; checked everything into repository;
QA should consider things DONE only when...
requirements are understood; analysed; suggested options to implement the best and improved usability; doubts clarified; written acceptance criteria; smoke tested the features in QA; acceptance criteria checked; boundary values checked; impacted areas checked; usability checked; translation checked; security checked; performance checked; cross browser compatibility checked; reported bugs in bugtracker; verified the resolved issues; demo is done; handed over to UAT;
Managers should consider things DONE only when...
objectives set for sprints; priorities set; analysed; designed; coded; integrated; built; installation tested; code/data migrated; features tested; change requests logged, communicated and recorded; communicated delays; risks analysed; contingency planned; issues fixed; ensured quality and value addition; reviewed by stakeholders; accepted by the customer; harvested the sprints/project; features and future enhancements documented;
Like the above example, every professional must have a checklist to tick it off before they say it is DONE. It should be a built in quality in every professional. Even if any one of the items in that checklist is not ticked, the task is considered incomplete. You might come across few missing items in the checklist during the project execution, it is recommended to add that to the relevant checklist as you go by, so the next time it will be taken care.
Partially finished features results in hidden costs to the company with an enormous and unpredictable amount of work. This screws up the release planning efforts and prevents from honoring our commitments. Partially done work often becomes outdated before it's finished, it always gets in the way of other work.
How many times you have hacked (temporary fix) the code and never visited again to fix it for good? How much time you had spent in reviewing and cleaning up your code before submitting to the client? How many times you have worked all the night and in the weekends to complete something and still not satisfied with the delivery? How many times you felt ashamed when the client finds out an obvious issue in your delivery? How many times you had to lie and be dishonest to yourself and the client about your awful planning and delivery? These are the questions that tells us how wasteful partially done work can be.
So to qualify ourselves as a professional, we must always ensure that when we say or consider that something is DONE, mean it and ensure that the checklist defined by us or an organisation has been taken care of, nothing is left over and ensure that the completed task will never come back to us again. After all, we want to deliver quality software to add value to the customer.
