Programming in teams

The common pattern that I find in “bugs that make no sense” is that I am believing something that isn't true. Once I identify and challenge that belief, the bug becomes obvious. The reason that these bugs are harder to find in my own code is because I believe my code is correct, so I don't question it so closely. When I'm reading other people's code I have less belief that it is correct, so less hindrance to finding the bugs.

Put another way: finding a bug in my code is both a success and an admission of failure. Finding a bug in someone else's code is pure success. This sounds like a strong case for pair-programming!
—Neil Brown, How to ruin Linus's vacation, LWN newsletter

• Common sense
• Science supports common sense
  Woolley, Chabris, Pentland, Hashmi, Malone
  Evidence for a Collective Intelligence Factor in the Performance of Human Groups, Science, DOI: 10.1126/science.1193147
  Psychologists have repeatedly shown that a factor called “collective intelligence” emerges from the correlations among groups of people's performance on a wide variety of cognitive tasks. In two studies with 699 individuals, working in groups of two to five, we find converging evidence of a general collective intelligence factor that explains a group's performance on a wide variety of tasks. This “c factor” is not strongly correlated with the average or maximum individual intelligence of group members but is correlated with the average social sensitivity of group members, the equality in distribution of conversational turn-taking, and the proportion of females in the group.
• Our personal experience in school
• That is how human civilization (should) works!

• Communicating
• Planning & Distributing
• The Psychological Factor: Difficult people by Karl Fogel, Producing Open Source Software

• Pair-programming
• Agile Development

• Meetings (presentations/progress reports), online (mailing-lists, IRC, Wiki), commit messages!
• Listen/read, think before you speak: productive vs. unproductive threads – bikeshedding
• Give and accept positive feedback, constructive criticism *only*, self-criticism, ask and offer for help (no need to be ashamed)
• Don't bypass team-mates. If it happens: no blaming – look for a solution instead
• Avoid private discussions

• Deadlines, milestones
• Identify compact and self-contained work packages
• Identify skills and preferences in the team
• Check progress often, identify bottlenecks, flexible re-allocation of resources

• Do you need a leader?
• A tyrant? A benevolent dictator? A release manager? A spokesperson?
• plutocracy (rule by the wealthy), aristocracy (rule by the best), democracy (rule by majority), do-ocracy (Debian ), anarchy (flat society – no authority/hierarchy)?