Feedback-Directed Development

I believe that the myth of the Benevolent Dictator For Life as project-omniscient prognosticator is pervasive but incorrect. While the need for a leader with the respect and authority to make a final decision is clear, this leader needs something other than complete and authoritative knowledge about how the project will eventually work. This leader needs good taste -- in design as well as community cultivation.

Set aside those characteristics for now. I want to ask and answer a different question. If the project leader doesn't know exactly what the software needs to do in complete detail, where does this knowledge come from?

I believe the only workable answer, at least for software that attempts to do new things, is "from a well-honed feedback cycle."

Some of my most effective debugging and design sessions have come from working with other people. In particular, I spent over a year working on a book with a close friend. We discussed and debated organizing principles and appropriate coverage and tone and approaches frequently. Of course we disagreed, but when we stood in his living room and rearranged sticky notes on the wall to divide topics into sections, or when we spread out index cards on my floor to separate principles by theme, we learned much more than when we produced individual plans in isolation.

You can predict what a book needs to contain and what its intended audience wants and needs (two very different verbs) to read at the start of a project. That's good business sense. Yet you must retain the flexibility to change your plan when you realize that it's not working right, or that it could work better.

The act of working in concert with another human being with different experiences and thoughts and biases and goals helped both of us refine our approach to cover what we needed to cover. I'd say "Let's use this approach," and he'd say "That's good, but what about this other idea you've inadvertently neglected?" and we'd refine our plan until it fit. We had the same high-level goals, but left to ourselves, the end result would have been far different. It was better for the rapid feedback.

We asked for feedback on draft chapters, and we received often voluminous responses. Some of our most proud ideas didn't hold up when exposed to our intended audience. If we'd persisted in our original plan, or if we'd eschewed rapid feedback in favor of the traditional model of user acceptance testing at the end of the project, our book would have suffered.

I believe software development works the same way, only more so.

The person with the vision for a software project must re-evaluate the plan against reality frequently. I believe that there is no better way to do so than to request feedback from the intended audience frequently.

That's one reason I encourage so strongly participation in community-developed software projects, and one reason I encourage so strongly the value (and even necessity) of frequent, small upgrades. Active participation brings your concerns to the attention of other participants. Frequent feedback helps minimize churn and rework, allows smaller course corrections, and establishes guideposts to mark whether an approach works or not.

I don't believe that this is the only way to develop modern software -- just that it is the most effective, especially considering the costs. (After all, what's cheaper: reeducating the world to upgrade their software more often, or changing the physical laws of the Universe to make change and risk irrelevant?)