A couple of weeks ago, I mention “definition of done” which many of my readers may have never heard of before. The phrase, “definition of done” comes out of the agile movement. But there is no reason why it needs to stay there. In fact, I would argue that many of the problems we have in the software industry are because most organizations only have one definition of done, “If we ship this today, can we make money?” When the Agile people talk about “definition of done” what they ultimately mean is, “if we were to ship this product today,and someone were to inspect what we’ve done, would we be embarrassed?” Definition of done, is about the quality of the code. When thinking about the definition of done, here are some items you might consider.
This is the most obvious. Of course for this to work, you have to have a user story that is specific enough for you to answer this question.
This one can fall through the cracks easily because documentation is the least favorite activity of a programmer. But, it isn’t necessarily a programmer activity. Remember, an ideal team has all the skills it needs. So, if you have a documentation requirement, be it an ISO requirement or simple end user documentation telling them how to use the software, your team should have someone on it that can produce this documentation.
I say “reasonable” here because the principle is high code coverage where we need it. To try to aim for some metric will cause us to write tests where we don’t need them. By combining a “reasonableness” level with code reviews, I think we can hit this target without setting an unrealistic arbitrary limit.
You’d think this one would be obvious. You have tests, you should be running them every time the code changes. But, I’ve seen situations where tests sit in version control and never get run. Run your tests!
Once again, this one should be obvious. Just because you have unit tests, doesn’t mean the system works. The main problem with the Federal Health Care web site that went live in the United States recently is because no one made sure all the parts worked together. And don’t leave this to manual testing. There are many ways of testing at this level that you can automate.
Once again, run your tests.
If there isn’t at least one other programmer on your team that understands what you’ve done, you aren’t done. I could, and probably will, write a whole post about this sometime.
I’ve talked about code complexity before. Just go read that post.
Again, there are tools for this. Find one and use it.
Compiling without warnings is something else I’ve already talked about.