Some people call me pedantic because I seem to have a checklist for almost everything. I like that because it’s true. :) Today, I want to share my Definition of Done (DoD). This is a list of questions I go through every time I finish coding a requirement, fixing a defect or doing another non-trivial task of software development. Every question has to be answered with a clear “Yes!” before I can consider the task done. Allthough there seem to be quite a few items in this list, the answer of the questions shouldn’t take more than 5 minutes. These 5 minutes however save me a lot of problems like when I nearly forgot to merge my code, hand over database skripts or whatever.

Code

1. Classes organized in business-driven named packages? “accounting.administration” with every class concerning the administration of accounting in it is a better package name than “accounting.service” + “accounting.dao”.
2. Does the DAO load exclusively the data used in the panel? Sometimes, maybe from earlier development, unnecessary data gets loaded.
3. Does the DAO load everything in just one query without lazy loading? Avoid unnecessary joins! While writing tests, look at the SQL queries in the log.

Database

1. Scripts for data migration written?
2. Hibernate schema validation successful?
3. Database scripts send to database administrators?
4. Database scripts committed to release branch?

Quality Assurance

1. Smoke-Test done? Use the most important parts of the software to make sure nothing broke during development.
2. If change was a defect: Made sure that this specific defect never occurs again? Can be achieved with JUnit tests that test this defect.
3. Thought about how new knowledge can be given to team members? New entries in wikis or small talks are a good tool to ensure everyone in the team knows new developments.
4. Non-trivial task: Code-Review with team member?
5. Used Degraph to make sure no cyclic or architecture-breaking dependencies have been introduced?
6. Report about software quality in ticket management system? After finishing a task, I write a short report about the most important metrics of software quality directly in the ticket of the change. That includes the before and after values of the following metrics:
   1. number of checkstyle warnings,
   2. number of TODO and FIXME,
   3. test coverage The task is only done if every value is at least as good as it was before the change.

Organisational Stuff

1. System- and/or user documentation updated?
2. If existent, feature-branch merged into release-branch?
3. If existent, feature-branch deleted?
4. Changed the status of the ticket in the issue management system to “completed” or “done”?

PS

Funny incident: Jens wrote about checklists just a few days before I began writing this article. Checklists seem to be “in” these days. Anyhow, I recommend you to read his article “Checklists for the win!”.

TL;DR

The last step of finishing a task like fixing a defect or implementing a feature, I check a couple of questions concerning the code itself, our quality assurance and some organizational stuff to make sure that my work is high quality and I followed the best practices of my team.

(Photo: raywoo, http://www.istockphoto. com/photo/task-accomplished-19610826)