I’ll be presenting on database refactoring and specifically dbdeploy at this year’s XTech conference. XTech 2007 runs from the 15th to the 18th of May in Paris, and my presentation will be first thing on the morning of the 17th.
See you there…
Update 1: OK, sorry for the change – but I’ve had to reschedule to Thursday 15th of March. Venue still tbc
Update 2: The venue is now confirmed as the Old Bank Of England
OK – I thought getting filmed by someone from Microsoft last year was as surreal an experience as I could expect from London 2.0, but I think a plug on Wired News which I came across in Gmail takes the biscuit:
Londoners’ calendars are once again full of networking events, parties and meetups.
The setting is traditionally a London pub and, in the case of events like Beers & Innovations, appropriate liquid lubrication is on tap.
No damn plug for the blog though – or me! I suppose at least one Sam (Sam Sethi) gets a sound bite – even if he does have nothing to do with the event 🙂
Anyway, after a not so brief hiatus, the next event will be on Wednesday March the 14th Thursday 15th of March. Details up as usual on the calendar, Upcoming and the official website. Venue tbc The venue will be at the Old Bank Of England, but please comment or update upcoming if you’re attending. QCon will be in town at the same time, so we may have a few gatecrashers…
One of the struggles people can have when they first start pairing, is understanding when it is time to drive, and when it is time to watch. Developing a good tempo to the act of pairing – and understanding when the change over should occur – can make it seem like a much more fluid activity. When it is working well, outsiders will see the keyboard moving backwards and forwards between the pairs (albeit perhaps slightly slower than a game of table tennis!).
If one pair member hogs the keyboard too much, the other member can feel that they are not properly involved with development. Depending on your development tools and build times, you may need to identify different points at which to pass control. The important thing is to ensure that both members of the pair get to feel equally involved in the development. Set yourselves a target for the maximum duration for each member to have control of the keyboard – ten minutes seems a good target to aim for, but a shorter duration may work better for you.
Example – Test, Implement, Refactor, Switch
When using Test Driven Development, a good way to develop this tempo is to use the acts of writing a test and making it pass to define when to change over. I’ve seen success in having the person A write the test, then have person B get the test to pass and refactor, then write the next test before passing the keyboard back to person A.
Extreme Example – Chess Clocks
This example was related to me by a colleague. The team in question had chess clocks at each pairing station. The idea was that each member of the pair got to drive for four hours of the eight hour day. To keep track, at each switchover they’d click the chess clocks to start the other persons timer. If at the end of the day if you’d used up all your time, you had to watch. Very quickly each pair worked out a dynamic in which the time became equally distributed – I’d certainly of liked some video footage though!
I’ve long been a fan of Amazon’s emerging webservices such as S3 or the mechanical turk – without doubt they are doing some of the most interesting things with web services anywhere on the Internet.
The mechanical turk is bridge between people who want work done, and people who want to do work. It handles payments, verification, matching qualifications etc. One of the first examples of it’s use was the art project to have drawings of 10,000 sheep done by people all over the world. Now Amazon have used the turk to help search for missing Microsoft Employee Jim Gray.
The turk is distributing satellite imagery of the area in which Jim’s boat went missing – and anyone with an Amazon account can help them out. I’m sure you can find worse things to do with ten spare minutes during your lunch hour.
magpiebrain 