It should come as no surprise to anybody who is a developer that software development/engineering is an industry that still continues to struggle with its growing pains as people remain uncertain, undecided, and unconvinced over the effectiveness of processes and practices past and present. In that constant search for the Holy Grail of development methodologies, we have in the past decade heard of the broad-thinking
Agile concepts that introduce new ways (ok, maybe not so new now) of developing software and working in general.
Being in Asia has serious disadvantages. I mean it, and let's be honest here. People are typically less daring and adventurous to experiment with new ideas in hope of improving. Even admitting to less-than-satisfactory accomplishment is a hurdle, which is a crucial factor blocking the view, and recognition, that there is room for improvement. Such is the case then that it almost becomes a lottery strike to find an entire development team (management to developers) who practise
eXtreme Programming branch of the Agile Alliance, and
Pair Programming to be more specific.
I don't want to regurgitate the "selling points" of Pair Programming here; those can be found in plenty other sites. What I wanted was
find out for myself just how far the formalisation of having two people sitting down at a _single_ computer to work on a _single_ task can take us. If you cannot find willing colleauges, then find friends in the community. Here's first hand experience report after spending the evening with fellow SgDotNet council mate Kit Kai:
Note that these are really just views collected from an exercise conducted in a few hours (with disruptions inbetween), and shall not be perceived as scientific and conclusive. ;-) The exercise is based on Chapter 2 of
eXtreme .NET, where we are put through the job of creating a Windows Forms screen saver. Actually, this perhaps becomes the biggest problem for us as it actually involves a fair amount of 2D graphics chores which both of us are unfamiliar with. More than once we had to look each other in the eye to request an explanation just what exactly the Navigator was telling to Driver to do, and had to look at the "model answer" code and read though the .NET SDK to figure out what of those methods mean. (Actually some of them were taught to me back in school, but that was nearly ten years ago - Lord grant us some persistent storage!) To be honest we only got through 80% of the exercise because it already became very obvious what we were getting out of it; completing it technically was redundant.
Real-time code review = instant correction
Admit it, we rarely write a good logic sequence the first time round. How many times do we write some block, only to later delete and modify drastically? Way too often. With the Navigator there actively there reviewing on the spot, catching elements the Driver failed to sense becomes much easier. Immediate feedback and suggestion can be afforded. Remember this rule of software development: it is cheaper to fix errors/flaws in
earlier stages of development than later. In the software construction phase, this is just about the earliest point of time issues can be spotted and addressed (thereby cheapest, albeit only done so by only one other individual). Compare this with hundreds or thousands of lines of code accumulated by week's end for code review, or being called to look at a colleague's problematic bug. Not only does it take longer for others to read through the entire lot and understand the logic, engaging in significant correction (if the matter is that serious) will cost the original author time.
Correct matching of skillset
It seems important that a pair, assigned to a list of tasks, have compatible and complementary skillsets. Meaning one should be more experienced in some tasks while inexperienced in the rest, and vice versa for the partner so mutually teaching and learning becomes an efficient proposition. In our case, we were both inexperienced with graphical drawing, and that left us both in "search mode" rather than one being able to guide and instruct. Given the complexity of chores and duties carried out in a usual project, this has the potential of upping the complexity severely for the need to micro-manage skill-matching as developers constantly switch partners throughout the week.
Constant interaction
Everybody should recognise by know that communication is key to successful projects, and working in general. This constant exchange of thoughts and ideas serve to give everybody good windows into their teammates' minds. While Kit Kai and I have already known each other for some time, it is clear how this will help distant colleagues gel together. Of course, as the book puts it as well,
maturity is paramount to conducting discourse that result in disagreement and debates. Arguments and quarrels
are avoidable. Another point is the constant interaction kept me more alert and "awake" - I was less likely to be distracted doing something else like reading email or having my mind wander. Many confess to possessing such traits as well, so helping each other pay attention to the "item of the moment" can't be anything but productive. Two dozing individuals in their isolated cubicles (ah yes, humanity....) cannot possibly be better than two individuals working and finishing a single job.
No hard guarantee on fast delivery, however
Cannot conclude this as the sure-win strategy that sawing together tree after tree is
really faster than just chopping a tree alone. The activity of Pair Programming might not result in faster completion of alloted tasks per se - skillset/experience, nature and complexity of tasks, chemistry between partners, lengthy debates/discussions all play important factors influencing the outcome. In fact, it appeared likely to us it may take longer actually.
But, that overhead of two people working on a single task is likely to result in better code (of course that is assuming quality architecture and programming practices are in place.). We were constantly reminded to ensure our code was compilable and workable after each stage. We think the everybody must understand the point is to help drive the quality up - high quality means less flaws, translating into less corrections and re-work. And we all know
that takes up a significant amount of time in the late stages of projects, don't we?
Can you convince your boss?
Still may not. Sorry for being skeptic. What is important is for everybody (not just the boss) to first be open and willing to accept that there
are better ways to do things. Being risk-averse as we are, it is likely this can only be allowed in a small-scale project or only a small group in a larger team of developers. I think it is apparent to anybody, though, the full effect and benefit cannot be significantly felt unless
everybody believes and does so.