Now, the company I work at produces games and games often have very fluid designs which can change and evolve as time passes so as to obtain that often mythical 'fun' factor. Indeed, game programming was probably the first form of agile development before the term was coined owing to the how games were often hacked together over time and generally evolved forwards towards the final product.
With this in mind we are indeed an 'agile shop' running short iterations on mini-games in order to develop things quickly, get feed back and adjust to find the fun. These periods are known as 'sprints', so called I would guess because you are racing towards the end of the period to get something done quickly.
The major part of this work is done in 'Scrums', small teams of people working on a game or two (often two coders and two modelers/artists) which generally works well, although depending on the art work to get done there can be a slight lag between the coder needing models to work with and the artist producing something, but we often make do.
Since around the time I started work at this company our lead programmer has been pushing the idea of trying out 'pair programming'; well, pushing is a tad harsh but he has mentioned it a few times and we've even had one abortive attempt at it when myself and another programmer were meant to work on something but due to time constraints we never managed to do so.
With this latest sprint the teams were drawn up and it was decided that a large and complex game would be a good test for pair programming, so myself and another coder who also hadn't been at the company long were tasked to do this. However, things didn't go well from day one as the design was effectively rejected by the publisher and a new game was produced, significantly simpler than the original I might add.
Once we had a design and we'd moved to desks next to each other the programming process could begin and this is where my first reservations began to appear. You see, with this particular project the first 3 hours or so is generally spent setting up files, placing tasks into our project manager software and getting a sane game into place so it compiles and doesn't break the build. Unfortunately this is a job which can only be done by one person, well we got some slight over lap when I tried to make the game via a script (however that failed so we didn't really gain much of anything).
Day 2 was a little better in terms of getting things done, but again we ran into problems. On day 1 our lead has said to us not to let egos get into the way, because lets face it programmers are an egotistical bunch who often believe our solutions are right and everyone else can burn. Generally things went ok, often the idea put forward by my partner was one I agreed with and went off without a hitch; however when we got to positions where we both had solutions and I didn't agree with his, well queue 20 minutes of talking to decided what to do.
This does to a degree come back to ego, however there are things which need to be taken into account;
If I was 'my ideas are best' all the time I wouldn't have agreed to times when he has put forward ideas which I wouldn't use myself but seem like good solutions and there was no advantage into doing it my way.
If only due to age I have more experience with C++ as such I can often see solutions to problems without really thinking about 'why' there are solutions
I have more experience with Lua; this means I know about scripting tricks we can use for configurations or general setup stuff (such as nested table loops to tie together ints and strings for file name and in game ideas or tables referencing tables).
In those last two situations I tend to want to push my ideas, indeed we ended up in a 40 minutes debate about the best level structure with him wanting to use his system and me wanting to use mine which was better as it used less memory (which was mostly down to my better knowledge of Lua) and was generally clearer; well in my opinion and in the opinion of our lead who voiced this after the fact.
Fundamentally with pair programming the problem is that of experience and seniority; even if its not in the company but in age thus granting the experience. In this instance I'm 27, nearly 28, with reasonably extensive experience in both C++ and Lua and not just in academic sense. On the other hand the person I'm working with is 21 or 22, fresh out of uni and mainly a C# programmer with little experience in C++ and virtual none in Lua.
The other program with pair programming is that of time management; we have a 7.5h working day, of which we effectively schedule work for 5h giving 2.5h a day for bugs and general 'wiggle room'. Today we removed 7h of work from our project planner, which on the face of it looks good, however;
This is only effectively 3.5h each
The tasks have a min length of 1h in the planning software as such even a 20min task costs 1 hour
Working singularly we would do the same, if not more work, which means at best you are breaking even and at worse losing time (if we managed 5h a day we would in fact be 1.5h down each for the day)
Time wise it isn't really a gain, the argument can be put forward that pair programming produces less bugs, however that isn't strictly true either. In my experience most errors are syntax based; often I'll forget a semi-colon or forget to include something; annoying yes but easy to catch with a quick 'compile'. While we have caught a few errors this way I wouldn't say it gained any over all time.
Secondly, when it came to logic bugs we haven't really gained anything; watching someone program, even when you talk about it, isn't overly interesting and, in my case certainly, I find my mind wandering. As such, while a few logic errors have been caught they are often things which would get caught with a quick run time test anyway; at the same time other bugs are still slipping passed. For example today we forgot to call an update function on another object, both of us missed it as we were so locked in on the bit of code we had just gone; this works both ways as while watching I have missed things and my partner has done the same thing when I've been coding.
That isn't to say it has been all negative, I've introduced my partner to a few new concepts he might be able to use in other mini-games.
While we are only two days into this experience I remain underwhelmed; I'm reasonably convinced I could have done more in a day than I have today, indeed I can often be productive for extended periods of time simply by putting some headphones on and zoning into the work with no fear of anyone distracting me.
With this system of swapping and talking it isn't as easy to 'zone in'; instead you spend the first few minutes adjusting your mind set again and then have this constant distraction over your shoulder. Apparently you are meant to swap from programmer to watcher every 15 minutes or so; however an hour seems to 'work' for us as it allows you to get things done.
Maybe things will improve over the next week or so, however 2 days I'm not impressed.
I do however see clear benefits in the information sharing you've mentioned. At such short scale it might not be seen as that big a win, but imagine you're working on a specific module of your engine, say sprites (in my case). If you work on it alone, nobody else will truely understand how it works. This can be helped with things like show-and-tell, or daily/weekly meetings. However, with pair programming there are now two people who know all about the system. When a bug is found in the module there are two people who can fix it. Assuming one of the two will pair up with someone else to fix the bug, a third person gains a deeper understanding of the code. This spreading of knowledge is a very good thing as it protects the company's investment in the code.