Rethinking Coders

The main problems

• Projects move very slowly -- way more slowly than expected.
• People who are the impetus for starting a project often move on before it's completed.
• Volunteer coders often implement changes without much coordination, leading to incompatible code.
• Entire projects are abandoned (or at least forgotten)
• New coders are often overwhelmed by the learning curve

Some analysis

What motivates volunteer coders?

• Some people want to learn useful skills
• Some want hands on experience
• Some want to teach others what they know
• Some just want to help out

Comparison with the Build Program

I often compare the Coders program with the Build program as a start to figuring out what might work better for coding at Free Geek.

In the build program, volunteers:

• can sign up for any of nine shifts per week
• need to work at Free Geek
• trade time building and QCing in exchange for something (often a computer, often skills)
• go through a Prebuild program where they are exposed to skills they'll need later on
• in prebuild, folks sometimes realize they're in over their head and drop out
• once you teach someone how to build a computer, they (basically) need to repeat that task several times

In contrast the volunteer coders:

• can come in once per week, but can work on their own time
• can work from home or elsewhere if they choose (though some things need to be done at Free Geek)
• trade time writing code in exchange for skills
• don't go through any prerequisites program
• sometimes realize they're in over their head and drop out while coding
• once you teach someone how to write a program, they cannot repeat that task several times in any kind of a useful way

The build program is quite successful at involving a lot of volunteers at Free Geek, while the coders successes are much more modest (and that may be putting it charitably).

Some (preliminary) conclusions

Get more organized

A common root of several of the problems is that work moves so slowly that coders drop out and work doesn't get done. We can approach this group of problems in two ways

1. speeding up the pace of development and/or
2. better planning and organizing
   • clearer definitions of what we want done
   • more "bite sized" tasks that can be accomplished in a shorter amount of time
   • better tracking of the status of tasks

An advanced coders group that plans out projects, and identifies the specific tasks to be done would give us a foundation for identifying the next task appropriate to a given volunteer that should be done. This would make us more organized to the incoming coders. (See #Extreme Programming at a Glacial Pace.)

We should look at ways to tie together our existing infrastructure to allow this. We will also need a tighter group of advanced coders (system designers, etc.) to keep on top of this.

Repeatable pre-coders program workshops

A series of repeatable workshops in basics could happen, comparable to the command line for builders class, for new coders. These could cover:

• text editing
• ssh / scp
• cvs
• unit testing
• hello world in:
  • python
  • php
  • shell
• hello world from the database in:
  • python
  • php

Extreme Programming at a Glacial Pace

Applying the concepts of extreme programming in a more conscious way might also help, but we might find obstacles to this when trying to maintain a sustainable pace. From Wikipedia comes this list of characteristics for extreme programming:

• Incremental and iterative developments - small improvements after small ones
• Continuous, often repeated automated unit test, regression testing.
• Pair programming
• User interaction in the programming team (Onsite Customer)
• Refactoring
• Shared code ownership
• Simplicity
• Feedback
• Organising the system with a metaphor
• Sustainable pace

Clearly we're not achieving a sustainable pace, and several other points could use some work. But this model fits Free Geek closer than most. We need to adapt it to our needs and prepare an infrastructure to make it work. Specifically, we need to have small enough tasks that are clear enough for us to hand them out to coders such that they can complete them and see that as an accomplishment.