It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.
chipper1
chipper1
/ types.markdown
Created
January 28, 2019 20:07
— forked from garybernhardt/types.markdown
chipper1
/ ddd.md
Created
January 28, 2019 20:04
— forked from zsup/ddd.md
Documentation-Driven Development (DDD)
The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.
- Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
- Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
- Once documentation has been written, development should commence, and test-driven development is preferred.
- Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
- When a feature is being modified, it should be modified documentation-first.
- When documentation is modified, so should be the tests.