I’ve just been watching the latest ScobleShow videos, which include a tour, demo and interview at Smilebox, a Seattle based startup producing a flash based platform for sharing photos, videos and music with friends and family. The service seemed quite interesting, although since the design aspect won’t work on either of my main machines here as one is a Mac (the service is PC only), and the other is running Vista-64 (the design software only works on Windows XP), it’s not really of much use to me.
However, what is interesting from a professional point of view is the point early in the video where we meet the programming team, who are developing using the Agile methodology, and more specifically, they are pair programming.
The basic idea behind pair programming follows the old adage that two heads are better than one. Essentially one half of the pair is the ‘driver’ who is the person actually using the keyboard, and the other is the ‘navigator’ who is thinking about the class that is to be written. The CEO of Smilebox makes a comment when he is introducing the team that he is sure that Robert Scoble has seen loads of people working like this during his visits, however Scoble doesn’t actually give an answer. Personally, I’ve not come across anybody working in a company that is actively pair programming, and I’d expect others will be the same. Even in organisations I’ve been involved with that have started to look at Agile Programming, pair programming is one of the most difficult ideas to sell to upper management, partly because to them programmers should be bashing away at their keyboards as much as possible, and in their eyes it will see a 50% drop in the amount of work produced. However actually seeing a team that is using the process, and hearing how quickly they can turn around new features, it certainly seems to be a good advertisement for the technique. Check the video out and see what you think:
In my experience when people talk about Agile methodology they don’t necessarily mean pair programming (if I recall correctly pair programming is directly associated to XP and Kent’s work), but more a general group of strategies such as DSDM and SCRUM. One of the more common things adoped from agile thinking is things like continous test and build and test driven development.
My concern with with some of the adoption of agile is the lack of overall structure informed by a product vision – the result is that you can endup spending more time refactoring the refactored rather than broadening the product/project’s reach.
Certainly that mirrors my experience. At SSE when we talked about agile it was continuous test and build, and test driven development, and not pair programming that we were talking about. Certainly would be interesting to know how many people are actually pair programming as contrary to what the guy in the video thought, my experience is not many!