Sure. It removes the bottleneck of fighting for control of a single keyboard and mouse, but there is still only a single screen. So why not use a version of this where each user also gets their own screen. It’s easy, familiar and cheap and works with any operating system – it’s called a separate computer.
While this may seem sarcastic, my point is really that one of the key reasons pair programming works is that it allows each partner to take different a role. While one is “driving” and concerned with the details of keyboard and mouse the other is free to consider larger issues.
I may be wrong, but it seems that allowing both to drive loses that benefit, and plunges both partners into the fiddly world of move, click and type.
A pleasantly witty yet insightful post about how different processes and methodologies can suffer similar problems, and how this relates to the individual learning journeys of practitioners.
Pair programming can be one of the hardest things to get right when attempting Extreme Programming (XP). It’s very common to give it a try and quickly find a whole bunch of problems. Mark Needham has written a thoughtful article full of tips on making pairing work. Well wortha read even if you don’t do it (much) yourself.
We had a small discussion at work a few days ago about the difference between Scrum and Extreme Programming (XP).
My take on the distinction is that Scrum is essentially a management technique, while XP is essentially a development technique. They certainly have a lot of overlap, but the different emphasis leads to some different recommendations. There’s no “40 hour week” in Scrum, for example.
pair programming is often one of the hardest things to “sell” when implementing XP or an XP style approach to development. Mark Needham has written a nice summary of some reasons for choosing pair programming.
At the moment, the company I work for is pressing forward on implementing an end-to-end agile approach to software production. With this in mind, I was intrigued to see an interview with someone who runs a company offering consulting and training in just this area, which they refer to as “industrial XP”. I found plenty of thought-provoking ideas in there.
A continual source of discussion is the XP/agile admonition to do “the simplest thing that could possibly work”. What is simple? How do you know it could work until it is done? What if part-way through you spot a “simpler” solution? “simpler” for who? And what does “simple” mean, anyway!!
Here’s an article which looks at this old chestnut from the point of emphasis – is it the “simplest” or the “possibly” which should carry the most weight?
Constructing sensible and effective user stories is a vital and sometimes surprisingly tricky part of XP-style agile software development. There are plenty of ways to choose a less than optimal story breakdown.
Lasse Koskela has put together a thoughtful blog post about this topic.
The Extreme Programming practice of “40 hour week” (a.k.a “sustainable pace”) is always one to provoke argument. Here’s a summary of some discussion at infoq:
the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”
That’s just a provocative snippet, of course. The article ranges much wider than that, and contains a lot of interesting stuff from one of the giants of software engineering.