Most current Agile toolsets treat source code as the primary deliverable of a project. This means that the source code gets special treatment: branches, labels, history, dependencies, etc. However, Appleton asserts that source is not the product: knowledge is the product delivered on a project. Source code is only one way to represent knowledge, it is a knowledge format. What follows is that the ideal toolset should manage all knowledge the same way, allowing tight revision control on diagrams, wiki entries, tests, etc.
Appleton then raises some interesting questions:
- How can we define "done" for non-code artifacts (e.g., a UML diagram)?
- Is it possible to apply TDD (test driven development) to non-code artifacts?
On a final note, the presenter mentioned a book that could be an interesting addition to our library: The Laws of Software Process, by Phillip G. Armour. (I don't think we have it, but I could be wrong...)