Don’t Like Pair Programming? How About Co-Programming?
One of the many ways in which I am weird is that I love pair programming (two Software Engineers working together on the same computer). I’m a social animal, and I have the self-confidence to appreciate corrections couched as constructive criticism. But many Software engineers hate it because they feel they’re being judged constantly. And of course a lot of Software Engineers are introverts or have poor social skills. Or just like a little breathing room.
At my last company, I was instrumental at rolling out Agile on selected projects (because I believe in using the right tools for the job, and because Agile was not right for every project). My current employer, alas, is nowhere near ready for Agile. We’re trying to make some major changes to a product that affect the Flex front end, the Java back end, the XML and XSLT documents that hold and transform some of the data, and the databases. All those components need to dance together, or someone’s toes are going to get stepped on. But there’s no one person with all those skills, and certainly not enough time for one resource to do it all.
So here’s what we’ve been doing; My partner in crime (let’s call him E. He hates that.) and I are working physically side by side, but not together on the same thing. While E’s flexing the Flex and pouring the Java it talks to, I’m torturing the data till it sings, and pouring the Java that manages the data. But when either of us has a question on how something should be working (E may have questions about what’s in the data to help determine the expected results, or I may have questions on how a particular query is formed or the results processed), we’re right there to point at things on our screen. The fact that we’re working on two different computers isn’t a problem because we’re both syncing regularly with the version control system.
Clearly this is not pair programming, because we’re both working on different things most of the time. But there’s something different going on than if we were both sitting in our own desks. The barriers to communication are very low, and we can point out stuff right on our screens because they are next to each other. It’s a great balance of supporting each other while still doing our own thing. I don’t know if there’s a real name for what we were doing, so I decided to call it Co-Programming.
This sounds very much like what Alistair Cockburn calls “side-by-side programming” in his excellent book Crystal Clear. (See p. 92-93.)
This is an excellent resource, which I highly recommend, and I would definitely call his mindset “Agile.”
As far as programmers feeling as though they’re being judged: it’s better to be judged by a trusted colleague in a safe environment, than to be judged later by customers in the market. Unfortunately, some workplaces encourage engineers to be suspicious of each other and to feel threatened by each other, which discourages this kind of teamwork and the success it breeds. (That’s one of Alistair Cockburn’s 7 characteristics of successful software teams, coincidentally.)
-TimK
Comment by Tim King | July 26, 2009
Although I’ve seen him speak at Agile Bazaar (a group I help run. I hope to write about our last meeting in the next day or so), I don’t have is book. However, I found a paper that describes side-by-side programming and references his book here which does make it sound like what we’re doing. Thanks for the reference to the correct name for it.
It’s very common, especially these days in this economy, for Software Engineers to think they’re competing with each other. That makes being judged by your cow orkers a bad thing in their eyes. I’m too confident in my abilities to fall into that trap. A competitive Software Engineering environment may push a few talented Engineers to go further and accomplish more, but the group as a whole suffers from fragmentation.
Comment by David | July 26, 2009
Yeah, I agree. And with the fragmentation, you don’t get that mastermind effect that makes healthy, functional teams both effective and a pleasure to work with.
-TimK
P.S. I wonder how many software engineers know of the “mastermind principle,” first set out by Napoleon Hill in 1937. I’m just getting familiar with it myself, but it might explain some of what happens in a properly working software development team.
Comment by Tim King | July 26, 2009
One more thing I just discovered: apparently, the entire text of Napoleon Hill’s original work, including chapter 9 (about the maser mind principle), is available on Google Books: http://books.google.com/books?id=c86H36mgiM4C
Comment by Tim King | July 26, 2009
Preschool teachers call this “parallel play”.
Comment by Chip | July 27, 2009
Yeah, but we don’t get milk and cookies and a nap in the afternoon. I could really use that after lunch at the Chinese buffet.
Comment by David | July 27, 2009
I used to take a nap in the afternoon. I’d find an abandoned office or storage room, especially one with a door and no windows, and I’d turn out the lights and close my eyes for 20 minutes or so.
Our brains are actually designed to switch out of “thinking” mode and into “daydreaming” mode once every 90 minutes or so. So: frequent breaks. That’s an Agile practice, isn’t it?
-TimK
Comment by Tim King | July 28, 2009