Has anyone tried any of this in a distributed environment? At my company, we all work from home. There are program like SubEthaEdit on the mac to facilitate file collaboration over a network.
With our new code base, everything is in an svn repository where all the commits send emails to everyone. Its made a big difference, as everyone can see and have some familiarity with the code, and catch possible issues by replying to the commit email with your concerns. Usually whatever is off then gets fixed and committed pretty quickly after the discussion of the issue is done.
This works well, but I do think there are situations where more transparency to the actual writing of code would really help, especially in cases where code one person writes is immediately needed by the other to finish their work. We mostly all work on the same server, and can open our working directories for read access by the group, but that can be a bit clunky.
Personally, I think that pair programming simply solves common problems that could be solved easier in other ways. Yes, I can pound in a nail with a sledgehammer. But it is often easier to use a carpenter’s hammer instead.
pair programming is a great concept, but does not work for most. So far as i have seen expert coders are introverts (with due respect for their skills). moreover it is very difficult to find a pair that can coexist and contribute, just like a good marraige! now i hope you know how complex this is !
One important thing to remember with pair programming is that it tends to be relatively noisy, at least compared to one developer working alone. It doesn’t work quite as well if you’ve got your developers sitting out in a cube farm.
In my first programming gig, I was awe-inspiringly green. I was hired as an intern, then due to the demands of their staffing requirements, I got promoted a week later to mid-level programmer. The good news is that the company was a firm believer in mentoring. My mentor became the Director of Development. My job entailed maintaining a production program in VB6. If I got stuck I was to go to the Director and talk things through with him (not any of the other developers… there’s a business rules reason for this, but it’s irrelevant to the story).
Wouldn’t you know it, but about a few weeks after, I got a task that the Director’s exact words were “normally I’d ask you to spin your wheels on this for an hour, but since I think I’d spin my wheels on this… why don’t we just sit down and you can look over my shoulder.”
Long story short, the Director did the coding. I’m familiar with VB6 syntax (Director programmed in VB6/.NET, C#, Python, etc. etc. etc.) He was impressed with the “paired programming” thing. I’d catch syntax errors and he’d start coding in C# (his primary language) and I’d say something like “wrong language”.
Of course, since it was designed to be a learning opportunity, I was the one who commited to CVS all the code… after I could tell my boss what it did and why in plain english. I’d say I learned a good bit in those few days (and the selling point is that my boss estimated it would take a week for the both of us, turned out taking only like 3 days).
Of Course, YMMV, IMHO, “past performance is not indicative of future results”, etc.
This doesn’t just work for programming. I manage the Internet group for a regional CLEC/ISP. When I got here I instituted change review for everything. My network people don’t make a routing, ACL, VLAN or IP change without review by at least one peer. The server team reviews each others configuration changes to services. This has stopped the knocking out whole cities worth of Internet access accidentally.
I’d love to try pair programming or peer review… unfortunately, our project leader is unlikely to agree. He himself modifies developers’ code without telling anyone (once, a change of his caused the loss of 95% of a database).
I’m surprised no one has explicitly brought up this point (although a few have touched on it). I can’t stand having people look over my shoulder while I’m working. The anxiety can get intense enough that I would just want to leave work early. I became a programmer partly because I like working alone. It sucks that the typical introverted computer geek as professional programmer may become a thing of the past.
I think there’s one other advantage to pair programming that hasn’t been touched on much here: it keeps people from goofing off. Face it, the internet is a huge temptation. Hell, I’m at work right now
I love doing pair programming because I want to learn all the tricks that other people might know. People who are too introverted to handle it should not be working in team environments anyway. And people who think they are too good to be working with someone else should be shown the door.
“I can’t help wondering if pair programming is nothing more than code review on steroids.”
@Jeff: I’ve heard Peter Provost and Brad Wilson refer to pair programming as “Real Time Code Review”. Where I work, we have called it that as well, from time to time, to remind ourselves of some of the additional advantages of pairing.
@Joseph Annino: yes, there are teams that do this (various technologies to assist). I can’t remember anyone specifically off the top of my head, but I have read of people doing this and using certain tools to make it work.
With a ping-pong methodology (TDD), both parties tend to stay engaged in the process a lot better. Focus is maintained and you get higher quality code. The keyboard switches hands every couple of minutes. Design decisions are tackled in tandem; better ideas emerge.
Pairing is more intense. Solo developers probably don’t realize how much time they spend doing things other than writing code, which tends to break up their day. What we’ve found with pairing is that the pair of developers needs to know how to manage their time: they need to take breaks, do spikes, research something, etc. They need time to fly solo to break up the intensity of the day.
When I review code, I am looking for:
Excessive callbacks to the databases and/or poorly formed queries (or poor performing)
Potential memory leaks.
Code not written in the correct Tier(Viewer, Business, DAO)
I rarely have time to check the business logic. So, I just look for things that could bring the system to a halt.
One of the problems seems to be that nobody wants to spend the time to
eally understand new code that does anything non-trivial, so the
feedback is usually very general. But later, when someone is working on
the code to either add functionality or fix bugs, they usually have
lots of feedback
because that is exactly what happens when writers ask developers to do a tech review on documentation. No one has time to sit down during the review period and think through what the text actually says (and doesn’t say). With rare exceptions, the best you’re likely to get is comparatively trivial comments on code samples. (Not, say, a comment that suggests an entirely new sample.) But oh boy, once you’ve actually published documentation that was only cursorily tech-reviewed, and that then proves to be incorrect or incomplete or lame, then people have opinions about what the docs should say.
I would say that unless it’s a central focus of your work – whether you’re a developer, editor, or whatever – reviewing other people’s work is never going to get enough priority, and will never be done in depth. Pair programming puts review front and center, which is probably why it’s more effective than code reviews.
My experiences with pair programming have been fantastic. Incredible focus and productivity, better code, reduced knowledge silos. I’m a big fan. Far more effective than code reviews.
Over at our office we have some sort of an in-between: four-eye commit. You develop on your own machine, but whenever you want to commit something to revision control, you call in one of your co-workers to show him all changes you made.
Since we combine this with small commits, this is like a code review multiple times a day.
