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.

There are several others discussing1,2 and proposing3 automated tools to ensure documentation-driven development. But so far, I have been exploring this more in terms of a manual effort4 and regular practice.


  1. Documentation Driven Development!
  2. On Documentation-Driven Development
  3. Documenation Driven Development (DDD)
  4. A practical guide to writing technical specs