We've all sat (or stood) in those meetings and listened to our colleagues and sometimes ourselves say those faithful words...
I am done.
- The Colleague
The problem is; many times; we do not all mean the same thing. Inevitably this will lead to many questions:
- Does it mean you are code-complete?
- Has it been tested (unit, compliance, accessibility, security, system, cross-browser, etc...)?
- Is it fully integrated?
- Has it been peer or security reviewed?
- Has it been documented?
- Is the graphic design work done?
- Is it under source control?
- Is it in CI?
- Is it deployable into production?
- etc, etc, etc...
Depending on who hears those words; and their area of concerns within the software development life-cycle; they will start making assumptions when they hear the word "done". It may seem silly, but the word "done" has a certain amount of power in the modern workplace, and for bean-counters it has a value/cost.
During my many years of doing contract work, I have seen a very similar scene play-out over and over again. Lets see if this sounds familiar to any of you.
- The contractor says "We are done." and then keeps charging for related activities beyond that point.
- Inevitably, the people being charged come back and say, "I thought you were done, what are these charges for?".
- Predictably, the contractor says "Yes, but we still need to do...".
In most cases, no one is lying, they just didn't have the same expectations for what it meant to say "done". The lesson here, is to have everyone align to a singular definition of the word and only use the word according to that definition. For those people who are charged with managing customer expectations, this can be particularly valuable, because it can ensure you have the same view of readiness and completeness as your development team. In many shops, products cannot be presented to Product Owners or Customers until the agreed definition is completely satisfied.
When I am left to define this on my own I measure "development" as "done" this way:
- The "code" has been implemented in a manner sufficient to meet all committed requirements
- The "code" has been peer reviewed
- The "code" has been security reviewed
- The "code" has at least 80% unit test coverage
- The "code" is auto-deployable
- The "code" is under source control
- The "code" is passing in CI
This is generally "my" minimum definition. Depending on the team I am working with, there may be things the team, the business processes, or Product Owners/customers require beyond that definition. You don't need to pay attention to my definition, but you should try and make this a bit more objective in your own environments.
One last tip... Be pedantic! Once defined, do not bend the rules. Once you start bending the rules the whole thing will fall apart again. Good luck!