The pair programming experience has continued at work, as it was always going to, and the third day was probably the better of the four so far.

While things did seem to go smoothly it also served to highlight another slight, although not earth shatteringly bad, issue with pair programming; scheduling and bug fixing.

Scheduling was the first "problem" which came to light, in fact I had realised this Tuesday night on the way home; the company I work for has semi-flexi time, in that as long as you are in the office between 10am and 4pm you can make up the other and a half hours when you want. For a few people this means getting in early and going home at 4pm, for others it means roll in around 10pm and going home at around 6:30pm.

Fortunately, for the most part, myself and my partner are on the same timing schedule; we both get in at 10am, both take lunch at 1pm and both go home around 6:30pm. Note 'for the most part'; Wednesday are slightly different, and this week more so, as my partner comes in at 9am as he can get a lift to the station. I, on the other hand, still roll in at around 10am because, frankly, the idea of crawling out of bed before 9am bothers me.

So, already we have a 1h disconnect where by he ended up doing work for an hour without me; this Wednesday was worse however as I was delayed by 30 minutes getting back from lunch. As such he was left coding on his own for another 30 minutes and finally, at the end of the day, when he left at 5:30pm I was left to code for an hour and half on my own.

The other issue is bug fixing in other mini-games we have written; during Wednesday we both had to abandon the work to go fix some issues with previous games. Mine was more minor than his so I finished first and, as we were working on his machine, was forced to spend some time idle again.

However, as previously noted these aren't earth shattering problems and we coped with them simply by going back to coding as normal with me joining after I got in.

All in all Wednesday went smoother than the previous two days when we were working together; maybe the code was just easy to write and there were limited ways to go about it, but for whatever reason it was just an easy day. That said, I still felt idle far too often for my liking.

Thursday was a different matter completely; it started off OK including agreeing that I'd have to write some code because I was more aware of what was being done having previously coded a mini-game using much the same system for data loading from Lua. However there came a point during the morning when, well maybe it was ego maybe it was a philosophical difference in how things should be done but for a while there was a real air of annoyance and general 'fine, you do it then.'-ness floating around and yes, it was from me.

Now, I get on with my programming partner fine, indeed the last few days have involved various jokes and light hearted ribbing but there is one major difference between us it seems; I'm a lazy programmer.

I mean this in a good way; if I know a solution to a problem already exists else where in the code base I will go off and copy and paste it into the area I need it, making any small adjustments as required. Indeed, when it comes to many tasks my first thought isn't "how can I program this?" it is "where can I get the code which is tested and does this for me?".

Today we hit a problem where I knew there was code in place in at least 2 games to do what we needed, it was well tested and known to work and would simply involve a bit of copy and pasting to drop it into place and use; it would also provide a consistent set of variables to the designers to tweak. However my partner decreed this was too complicated and insisted he should write a new system revolving around gravity. In the end he spent approximately twice as long writing and debugging the code (which, in my opinion, doesn't have meaningful numbers to tweak) as it would have took to drop in this prewritten code. However all during this time I was basically not paying attention, maybe it was unprofessional but it is one of my pet annoyances.

However, it wasn't just me who did this, I can't recall the precise details but later in the afternoon when I was doing the coding there was something I was going to do which he couldn't see what I was aiming at, disagreed with my way forward and ended up sitting just inside my peripheral vision bouncing slightly on his chair and radiating general annoyance in my direction. The worse of it was that I was dealing with things he had known knowledge of so as such he couldn't really advice me as such. Indeed at one point during the afternoon while I was trying to work through the logic in some script he suggested that we drop the pair programming and that he should do something else while I swapped back to my machine which is how the day finished.

I would like to point out that I'm not dismissing pair programming or indeed writing it off wholesale; more relaying my experience thus far. However I think that, beyond the issues I have listed thus far, the main problem is the kind of project we are working on.

While discussing how things are going with my lead and producer today I voiced the opinion that we were losing time (while our project planning burn down chart shows impressive work load cleared you have to half that and keep in mind that we overestimated by far too much) and that right at that moment I didn't see the practise as working all that well. To which he replied that it wasn't so much about the time as about catching bugs and being more productive and we'll see how it turns out in the project post mortem when the number of bugs are reviewed.

However, this again comes back to the type of thing we are working on and also to experience. I in fact replied that point by saying that I wasn't so sure we could judge as such as while this project might well have less bugs that doesn't also mean a win for pair programming; instead we are both a couple of games in now and are more used to the system as such we can see a bug and go 'oh, that'll be caused by X' and general produce less bugs over all. Indeed, over all I've probably had a lower bug count than my programmer in the two previous games and I'm obsessed by fixing memory leaks as soon as they come up (his last mini-game was leaking nearly 2Meg for nearly the whole project, in contrast when I got a 144byte leak I fixed it right away).

The other thing is the technology we are using; this is a PS2 game, the last in a long line in fact, so the technology behind it is well tested and well tuned, as such bugs are rare for the most part and often easy to find or simple logic errors. In such a situation, where the code isn't reused or revisited by anyone else (indeed, after this game it is all being thrown away as far as I know) having everyone understand it isn't all that helpful.

I do agree with the comments made about information sharing and API clarity; in fact for pre-production and system level code I could see Pair Programming being a great help, certainly when you are striking out into new areas. However when you are treading the same ground with what is pretty trivial code I can't help but think it is a waste of resources to tie up two programmers (something we are short of on this program anyway).

Still, the experiment will continue of course and maybe it'll turn around in the last few days, who knows.

My main hope is that some of the things I have taught my partner will stick; mainly in the Lua and container area as they are good solutions. In fact, towards the start we had a discussion about should we load the config data into a pre-sized array or use the framework's STL Vector like container; he favoured the hard coded method with a set limit higher than what we were told because "it should never get that far". However, having had two games change under me in moments I'm far more paranoid about designers coming over and saying 'the publisher would like X' or 'Can we do Y?' and these fixed limits going out of the window.

Today my paranoia was proved right as towards the end of the afternoon a designer did indeed come over with feedback and ideas and those hard-coded limits would have been a problem. Although this has lead to another one of those situations where from the conversation I have grasped quickly the changes needed and even got the code laying out in front of my eyes in my head and my partner hasn't grasped it so more time is spent trying to explain the way forward to him.

So, in conclusion, I'm not writing off pair programming at all, I just think this was the wrong game/project to try it on. In fact I will probably make a point of pushing for it in newer tech games assuming I get moved to one soon enough for it to make a difference. It's not without it's faults, but then nothing is perfect so I can live with that.