Skip to content
- For anything beyond a small fix, write the spec before the code and get it confirmed
- A spec states the problem, the observable behaviour, the acceptance criteria and the non goals
- Include what you will not do, and why, because that is where misunderstandings hide
- Describe behaviour and interfaces, not an implementation walkthrough
- List the open questions explicitly rather than resolving them silently with an assumption
- Keep the spec in the repository next to the code, so it is reviewed and versioned like code
- When the implementation reveals the spec was wrong, update the spec first, then the code
- A spec nobody disagreed with is not necessarily agreed, ask for explicit confirmation