Our Definition of "Done"
Quality should be present in everything you do, but it should be balanced with the time you spend working on a feature. Does it feel like you’ve been working on this feature for a really long time? Maybe you have. Is it “done”?
That is a tough question, so I’ll write down our definition of done.
When is a feature done?
- The feature does what it is expected to do
- If it has a user interface, the UX is simple and good enough: A human can use it!
- If it is code for other programmers, the public contract is clear: A programmer read the documentation and use it
- It has a decent spec , which covers at least two scenarios (not just the happy path)
- It is fast!
- The build passes (it doesn’t break any of the existing specs)
- The code is easy to maintain (DRY ‘ed)
Have you spent 2 days in a feature that should’ve been done in 2 hours? Have you spent 2 hours on a bug fix that should’ve taken you 8 hours? If so, why?
If the feature is big, break it into smaller features. This will make it easier to move ahead.
Before you submit your pull request , make sure that you have considered this list.