During the past few months, I have been experimenting with something called Documentation-driven Development. The idea behind such an approach is to ensure that the documentation for every known aspect of the application is written first and then, the associated program is implemented. This guarantees that the goals of the program is well documented.
One can find analogy to test-driven development where, for every code change, associated unit tests have been written. Documentation-driven Development to be clear, is not aimed to replace test-driven development but rather augment this approach. Therefore this approach can be summarized as document-program-test-repeat.
I have been exploring this idea with all my experiments and documenting my progress here. Consequently based on the results, I want to put this into practice in all my professional works.
What aspects of an application need to be documented? All aspects, i.e., every aspect that a new or regular user needs to understand concerning the application ever since its inception to the ongoing works and issues as well as the future tasks.
- Requirements: Motivation, Application purpose, resources involved, allowed operations on resources, targeted platform details, use cases, user interface mockups
- Design and Development: Architecture, chosen programming language(s), data formats, external libraries, data storage details, application programming interface
- Testing: Unit tests, functional tests, integration tests, stress tests, performance tests etc.
- Analysis: Memory usage profile, code coverage
- Manual: Installation Guide, Quick Start guide
- Administrator Manual: Installation and setup guide, configuration details
- User Manual: quick start guide, complete manual
- Developer Manual: API manual
- Issues: Past and current reported as well as their current status
- Feature Requests and Future Tasks: Possible future timeline of feature requests
- Changes: Change in any one of the above needs to be documented