Programming in teams

A plea for pair-programming

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

Why program in a team?

  • 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!

What are the problems?

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

Suggestions

Sprint-based development
  • Pair-programming
  • Agile Development
Communicating
  • 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
Planning & Distributing
  • 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

The Question of Leadership

  • 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)?
 
programming_in_teams.txt · Last modified: 2012/09/03 14:15 by tiziano
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki