or "How to Code When You Don't Write Code"

The idea of "Document Driven Development" was brought up today in the Habari IRC
channel. One of the things that the Habari Community has held as a core ideal is that users, developers, and designers are all equally important to the long-term health of the project. Also, it would be foolish of us to believe that all of the great ideas for how our software should work are in the heads of the people with the skills to translate those ideas to code. However, anyone can write a description of how they feel something should work. By documenting processes or structures a framework can be drawn up that allows the coders to have a well-developed jumping off point.

One example of this is that many of our coders don't do podcasting, but it is a feature that we really want to support. This is a great opportunity for someone who does podcasting to create a document on the wiki describing the ideal process for creating and distributing a podcast from within the Habari admin interface. This allows the people working on the background code to have specific goals to work towards. By using this document driven method, we're able to take advantage of both the podcaster's experience and the coders skills to the greatest effect.

Hopefully we can work out a streamlined method of connecting experience and skills in this fashion so that Habari continues to take advantage of the strong community we've built.