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.

There is a lot of discussion happening on the Habari mailing list about the design of the Administration interface. And it's the kind of thing that we're going to have to watch carefully to prevent it from getting ugly. With all the progress we've made, this is one of the first major tests of the strenght of the Habari Community. My own experience in theater has shown me that design is complicated, and the more designers you have working on something, the harder that gets. At some point, when working with other designers, someone's concepts are going to have to be subordinate to another's. If you're putting on a production, and the scenic designer is designing a setting in modern New York City, while the costume designer is basing their designs on 1940's Europe, and the sound designer is using 1970's protest music as their base, you're going to get a mess on the stage. This is why, in theater, it's usually the director who provides the over-arching vision, and a production manager is responsible for coordinating the elements and keeping lines of communication open.

But even so, while it's easy to say "We're going to need X amount of lumber to build this platform." Chosing the shade of blue to paint that platform is something that everyone can have a different idea about without anyone being "wrong".

In Habari we face the same issue. We can agree that a particular bit of code works or doesn't work. And it's usually easy to quantify what's "better" in the code. Does it use less memory? Fewer lines? Is it more secure? Easier to use in multiple places? But things like the width of the text entry fields can have a different answer for every user. In the case of Habari, we've also eliminated one of the simplest ways to resolve these issues. We don't have a person who is "in charge" who can simply say "Do it this way." We don't have a "director" and we like it that way. But this is when removing that centralized authority creates difficulty for the project. We must come up with a model that will allow us to come to a community consensus as to what Habari will look like. Because there is no "best" when you're dealing with something that is primarily subjective, a "veto on technical merits" isn't an option. The common element between where we are in Habari, and what I've learned from theater, is that it's an issue of communication. Designers, coders and users speak different languages and there's always the risk of things being lost in translation. Building common vocabulary is where we need to start if we're going to succeed. We have to take a large number of ideas and somehow create something that is visually appealing, user friendly, innovative and comfortable all at the same time, and we must somehow do this without sacrificing our primary principal of community inclusion.

This is our first big test. I don't know how we'll work through this, but I think we will all benefit from the lessons we're going to learn about how to design by community without ending up with something that looks like it was designed by a comittee.

As of today, I am officially a member of the Habari Project Management Committee. In all honesty, I'm a little overwhelmed with the trust that the other members of the committee have placed in me, and I hope to live up to that trust. I'm excited to be a part of this project, and hope to be a part of its future in any way that I'm able.

I am not a coder (or at least not much of one), which is, I think, an illustration that the PMC is focused on the best product for the user, rather than the best product for the people writing the code. What I hope to do is help make sure bugs are tracked well and acted upon and make sure that we don't lose sight of the fact that most users aren't coders and don't really care how a given feature works, as long as it does work.

Thank you for your faith in me, fellow members of the PMC. And to the rest of the Habari Community, I'd like to say thank you for creating an environment where it's fun to be active and it's easy to keep up the motivation to work on this project.