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.
- 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”.
- Does the DAO load exclusively the data used in the panel? Sometimes, maybe from earlier development, unnecessary data gets loaded.
- 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.
- Scripts for data migration written?
- Hibernate schema validation successful?
- Database scripts send to database administrators?
- Database scripts committed to release branch?
- Smoke-Test done? Use the most important parts of the software to make sure nothing broke during development.
- If change was a defect: Made sure that this specific defect never occurs again? Can be achieved with JUnit tests that test this defect.
- 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.
- Non-trivial task: Code-Review with team member?
- Used Degraph to make sure no cyclic or architecture-breaking dependencies have been introduced?
- 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:
- number of checkstyle warnings,
- number of TODO and FIXME,
- test coverage The task is only done if every value is at least as good as it was before the change.
- System- and/or user documentation updated?
- If existent, feature-branch merged into release-branch?
- If existent, feature-branch deleted?
- Changed the status of the ticket in the issue management system to “completed” or “done”?
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!”.
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.