Pair Programming With Ben Nadel
Like many developers, I've had a hard time getting into TDD and pairing. My clients won't pay for pairing (which is probably just as well as I'm the only full time programmer!) and I'm not sure that I can justify the overhead of TDD for the many projects I develop which are one time developments rather than apps which are maintained on an ongoing basis. However, almost all of the developers I know who are smarter than me use TDD religiously and pair frequently, so I've been spending a lot of time reading up on best practices. Last night really sold me on both practices.
We started to develop a very simple BaseObject, starting with the simplest tests for object instantiation we worked up a good chunk of the BaseObject functionality and even though I've built a lot of such Base Objects before, we both ended up being surprised by some of the directions the design took and definitely ended up with a much better class file and set of tests than either of us would have been able to come up with on our own.
There was no loss of focus, no getting really stuck (the other always had an idea) and a lot of the typos that usually wouldn't have come out until a test was run was caught while the other was typing, saving time. The naming and the hints were much easier with two developers bouncing ideas around, and I was converted to a number of Ben's default programming conventions as I saw how much more readable they made the code for both of us.
I was really surprised by how big a difference the process made – especially for key functionality (like framework code) where the quality of the design is key. I'm also sure that neither of us would have stuck with the TDD if we'd been alone, but the more we did so, the more compelling the benefits became.
I would say that pairing is a great way to get started with TDD. Even if neither of the developers has much experience, it's still much easier than getting started on your own, and while two of us learning TDD while trying out pairing for the first time probably weren't as efficient as if both of us had been knocking out code without tests on our own, the speed was much quicker and more consistent that I'd expected and I'm definitely going to do more experimentation with pairing whenever I get a chance and am going to do my best to use TDD as a default approach for all new projects going forwards.
What's been your experience with pair programming and/or TDD? And for those solo developers out there (or remote devs), how do you go about pairing?
At one point, Peter looked up and said something about not having checked any blogs. And it was true - over the course of a few hours, I hadn't checked email, I hadn't checked a blog - nothing. And the truth was, it hadn't even occurred to me. When I think about a typical day at the office, how much of the time does my mind wonder? How often does it occur to me, "Do I have any new emails?" One of the most enjoyable things about pair programming, from what I saw last night, is that it is so fully engaging - so much back and forth and sharing of ideas and talking things out, that you are actively thinking about the project the entire time.
I have to believe that this environment is, especially when you get really used to it, way more productive and able to produce higher quality work than just working by yourself. The benefits of having someone else there the whole time, even if it's just to bounce ideas off of, is immensely useful.
Definitely a highly recommended adventure.
Keep us updated.
I don't get to pair often, but when we do code dojo meetings its "all room collaboration" which is also fun, but sometimes results in too many opinions. Two is normally good.
1. I'd get bored when I wasn't driving, and
2. I'm not social enough to handle it. :-)
Those, of course, in addition to the conventional objections like assuming it would be more productive to have each developer work on separate areas of the code to "double" the output. It still feels counter-intuitive to me that this could work in a real way over an extended period, but I've been wrong once or twice before.
I know what you mean as far as boredom and productivity. But, one you start doing it, you realize that you don't get stumped. When you come up to a problem you are not sure to handle, there is someone right there at all times to help you think it out or to drop in with a fantastic suggestion. So, while you might not *seemingly* be able to get as much done at one computer, the rate or work, I think is done faster when you get the hang of it; and, with two heads, I dare say the work is of a higher quality as well.
It's always appealed to me on a visceral level, but I've never actually sat down and "just done it". Of course, most of my team these days is headquartered in India, so there's probably not much chance of success with that kind of distribution. :-)
That leads me to wonder - mostly out of curiosity - whether anyone's either tried or even doing pair programming in _any_ sort of distributed environment.
Doing that in a distributed environment has got to be difficult. However, I suppose with some sort of Connect type of screen sharing, it would be possible.
@Sam, I've tried code dojo style and I think I prefer two people - keeps things focused. I'd rather break a team down into pairs and then come back for a code review every couple of hours.
@Rob, It's actually really engaging when you do it - I think it's a great peer learning tool as well as a way to get code done quickly, and while I know many people wouldn't want to pair 8 hours a day (it can be intense - 6 hrs a day is plenty I've been told), it definitely has a place.
@Rob, I asked a while ago on the XP list and distributed pair programming is possible, but most agreed it's tougher than doing it locally. Key is high bandwidth interaction, and some users swear by screen sharing/vnc while others like editors designed for remote pairing.
I could see this as a fun alternative to the normal presentations at a conference. Some people might think watching two dudes hack at code for an hour would be pretty boring, but I don't know... seeing good minds at work, thinking out loud.... I bet it'd be rad. There's something about the raw decision making process, as opposed to the after-the-fact, synthesized stuff we get on blogs and articles, that is pretty damn engaging.
http://www.pbell.com/index.cfm/2008/4/29/Pair-Prog...
Any idea if this connect presentation will be available afterwards, or is it a catch-it-or-miss-it kind of thing?
my co-developer and I have two completely different approaches. he thinks things out and studies it until he feels it is ready to go. I tend to code a line see if it works, code another and see if it works. Though the talking out the problem works wonderfully (reasons expressed by ben.. getting to utlize two developer minds instead of one), the flow of getting to the problem is frustrating for both of us. Him because I move to fast and me because he moves slower.
hope that makes sense.
Without a very specific process like that I think it might have been much harder to get things done and I'm sure we'd still be discussing the optimal API. This TDD stuff really rocks!
I think I came away from that course more convinced about TDD, coding to interfaces, not repeating myself, separation of concerns and AoP than I did about Spring in general!
It'll be recorded, but please do try to make it to the live event.