The book Producing Open Source Software: How to Run a Successful Free Software Project is a fantastic reference for anyone involved in a software project – whether you're running the show or not.

In addition to the dead-tree edition, the book is available in an appropriately open source free format at the official website. The entire book is great, and worth a thorough read, even if you think open source is communism.

My favorite chapter is the one on communication. While important on any software project, communication is especially vital on open source projects, which are "bewilderingly diverse both in audiences and communication mechanisms." One particular pitfall of open source projects is that, if you don't manage the project carefully, you can tend to attract developers who are more interested in discussion than writing code. It's a subtle but pernicious problem – communication gone wrong.

Although discussion can meander in any topic, the probability of meandering goes up as the technical difficulty of the topic goes down. After all, the greater the technical difficulty, the fewer participants can really follow what's going on. Those who can are likely to be the most experienced developers, who have already taken part in such discussions thousands of times before, and know what sort of behavior is likely to lead to a consensus everyone can live with.

Thus, consensus is hardest to achieve in technical questions that are simple to understand and easy to have an opinion about, and in "soft" topics such as organization, publicity, funding, etc. People can participate in those arguments forever, because there are no qualifications necessary for doing so, no clear ways to decide (even afterward) if a decision was right or wrong, and because simply outwaiting other discussants is sometimes a successful tactic.

The principle that the amount of discussion is inversely proportional to the complexity of the topic has been around for a long time, and is known informally as the Bikeshed Effect.

We've struggled with this on Stack Overflow, too. The broad soft questions tend to get much more interest and attention than the narrow, technical coding questions that we originally intended the site for. We've made adjustments, but it's an unavoidable aspect of group dynamics. Who are we kidding? It's fun to discuss what color the bikeshed should be painted. Everyone has an opinion about their favorite color scheme.

What many people don't realize is that the bikeshed effect is, in fact, a form of procrastination. And it can suck in highly technical developers, along with everyone else.

The psychologists handed out questionnaires to a group of students and asked them to respond by e-mail within three weeks. All the questions had to do with rather mundane tasks like opening a bank account and keeping a diary, but different students were given different instructions for answering the questions. Some thought and wrote about what each activity implied about personal traits: what kind of person has a bank account, for example. Others wrote simply about the nuts and bolts of doing each activity: speaking to a bank officer, filling out forms, making an initial deposit, and so forth. The idea was to get some students thinking abstractly and others concretely. Then the psychologists waited. And in some cases, waited and waited. They recorded all the response times to see if there was a difference between the two groups, and indeed there was a significant difference.

The findings, reported in Psychological Science, a journal of the Association for Psychological Science, were very clear. Even though all of the students were being paid upon completion, those who thought about the questions abstractly were much more likely to procrastinate – and in fact some never got around to the assignment at all. By contrast, those who were focused on the how, when and where of doing the task e-mailed their responses much sooner, suggesting that they hopped right on the assignment rather than delaying it.

This is one reason why I'm so down on architecture astronauts. I find that the amount of discussion on a software feature is inversely proportional to its value. Sure, have some initial discussion to figure out your direction, but the sooner you can get away from airy abstractions, and down to the nuts and bolts of building the damn thing, the better off you – and your project – will be.

Put another way, what's the hardest thing you have to do every day? Deciding what to ignore, so you can stop procrastinating and get stuff done. The next time you feel yourself getting drawn into a protracted bikeshed discussion, consider: shouldn't you be building something instead?