Do you want to be a co-developer?

Raph Koster has a fascinating slide show he presented to the 2007 Games Development Conference.  I like to keep a weather eye on the games industry, because they know a *lot* about how to engage people in the art of learning.

In his presentation, he offered a slide with these points:

  • The fail fast, fail often method: “users must be treated as co-developers”
  • Google discards 80% of new features
  • They often prototype and deploy within two weeks.
  • Release early, release often: Flickr issues releases as quickly as every half hour

This is the MO of Web 2.0.  It’s dizzying, and fascinating.

And it’s cognitively costly. It’s one thing for those of us whose jobs revolve around keeping up with what new functionality is being explored on the web and how it can interact valuably with other functionality to be downloading stuff, figuring out how it works and finding out that it doesn’t work quite right and sending feedback to the vendor about it.

Similarly, leading edge gamers are often willing, and enthusiastic about spending their leisure time helping to shape the future of their favorite playgrounds.

But it’s crazy to expect that people whose jobs do not revolve around this stuff, but who are on company time trying to get a rather different task list attended to,  should be willing, let alone able, participants in the “co-developer” experience. It’s even crazier to expect that their employers are interested in paying them to spend time in this role.

Organizations need stable platforms on which to support training and online collaboration, so that their employees can concentrate on the content of the training and the work on which they are collaborating, instead of spending endless cycles spinning their wheels, figuring out how to use the @#$% tools.

We need to apply the stuff we know about adult learners to our technology roll-out process. It makes sense to invest in a full-featured platform, but it may best to roll out the features over time, incrementally, so that users have a chance to learn the interface and master it at a comfortable pace.

At Q2, we depend on feedback from our customers to guide our efforts as we continue to develop our software. But we work hard to keep the participant interface intuitive and stable, and we sort of think that we should be responsible for the testing and bug finding, so our customers can just get down to work.  When bugs slip through, it’s embarrassing to us. That may be a little old-fashioned, but for the moment, I think we’ll take a pass on the “user as co-developer” trend.