My favorite agile software development method, is Pair Programming. It is a technique where two programmers will work together at a single computer, working on the same project or component. One is known as the Driver, the person who is actually writing the code, and the other is the Observer (of Navigator if we want to use the Car Driving or Piloting terms) who is looking for bugs, looking for solution, and just all around throwing out ideas to the driver.
In my experience using this technique, the Pair of Programmers swap between Driver and Observer throughout the development of the component they are working on.
The process was probably created organically verses someone actually just thinking up a new SDLC Method, two programmers who were probably friendly around the office decided to work on a problem together and sat in the same cube or otherwise next two each other.
This has been my experience as well. I did not know I was participating in a truly established Software Development Technique, until way later in my career and I started reading more about SDLC models and the like.
A coworker who I was working with on a project and I started to become friendly, and at the time I was a junior developer, especially in the realm of Large Scale Web Applications, and he was hired as a Senior Web Applications Developer, actually the first on our small team. I had some personally experience with creating CGI scripts and it’s one of my God Given Gifts to be able to extrapolate things (especially computer things) very quickly, given very little information, and I had him help me setup a Servlet container server on my local workstation, so I could help develop the Servlets and JSP pages, which at the time I had no experience with. He naturally took the lead, but quickly saw, that although I lacked the experience with Web App development, I did have very solid programming and database skills, so we would start passing code back and forth through shared drives, emailing ZIPs, etc, and then we released why should we waste time doing that when we sat just one row of cubes away from each other, so we started sitting together at his cube (because his row was more empty than mine, and we could talk louder without bothering other developers around us).
He might have known the term Pair Programming without my knowledge, because he often used the Driver and Navigator terms, I knew what he meant by each of them, because he especially in the beginning started saying would you like to Drive, and stand up to switch seats, etc…
I find Pair Programming very effective for training junior developers as well. Currently at the time of writing this blog entry, I have a pair of more Junior Developers working in this type of format right now, and I strategically placed their cubes right next to each other without a partition so they can roll back and forth on their office chairs and switch very easily between Driver and Navigator, it has been working great, and both of them have been coming up to speed on helping to develop larger and larger components more quickly than I first anticipated. The Tech Lead who runs the team I have these two developers reporting to, was quite skeptical at first, but even he has turned around and started giving them larger projects to work on. I very happy with their progress, and although they are both extremely intelligent developers, I attribute the speed at which they have been able to work and deliver within a high stress enterprise level environment, to the Pair Programming model which they have been working in.
No developer can possibly know everything, and having another highly skilled developer watching your back can be invaluable especially when you are under the clock to deliver products quickly and without bugs.
You can read the Wikipedia article on Pair Programming, for the details on it, but honestly it’s a small article, and there’s really nothing to the model, other than you have two programmers that have a good rapport with each other work together at a single workstation (or better yet two workstations right next to each other, so that the Navigator can lookup API docs and other tips in the MAN Pages or the Internet, or other online reference source, quickly, while the Driver continues writing code.), working on the same project or component, and each of them play both the roles of the Driver and the Observer/Navigator. Again the Driver is the person who is writing the code at a given moment, and the Observer/Navigator is the one looking over the Drivers shoulders, looking for bugs on each line of code the Driver is writing (this reduces bugs in real time), and is constantly thinking about the next component or function of the current component, so the Pair can very quickly move on writing the code. The Wikipedia article on this says the Driver is working on the here and now or tactical aspects of the code, writing the lines of code in real time, while the Navigator is reading the lines of code looking for bugs while thinking about the strategic aspect of the code.
I also have found that if you setup a large enough cube or work area or the two developers, so the Navigator could quickly lean over and start typing on the Drivers keyboard while still wearing the Navigator hat to quickly fix a bug, etc, this is extremely helpful and again produces a better quality of code.
Pair Programming needs to be embraced by management of course, because it is easy to mistaken two programmers goofing off or the Navigator not really doing his or her job, but this is a big misconception, the Navigator is playing a very crucial role, in helping to produce quality code with a reduced time to market, and shortened QA/SIT cycles. Also if you as a manager associate a particular persons cube with the person who is the Driver all the time, you are mistaken, the two programmers may simply fine that particular cube move comfortable, or perhaps, the programmer who is physically assigned to that cube has a better workstation or better development tools installed, etc.
As I stated in this article, no single developer can possibly know everything, and an even bigger problem is that sometimes, quite often actually, when working on large scale projects, a developer can easily fall into a rut and have tunnel vision when trying to write a component to solve some problem. This is the programmer’s equivalence of Writers Block. A typical technique for solving this problem is to walk away from your desk, maybe get some fresh air, or to sleep on it, etc. Pair Programming however offers another solution to this problem, because for one thing it takes some weight off your shoulders and with two people looking at the same issue, often, someone will spot a solution that both of them working separately may have never come up with.
I look at it like the two programmers constantly bouncing ideas off of one another. Just like brain teasers gets the creative juices flowing by allowing dark neural pathways to light yup like a Christmas Tree, I believe a small group of individuals with similar skill sets do the same thing because the human brain is quite remarkable, and we are social beings and together just talking to each other (Keep Talking by Pink Floyd quickly comes to mind), seems to have been the key to humans creating an advanced civilization, at least to me. You never know what small seemingly insignificant statement, just a couple of words even, that the Navigator mentions to the Driver, lights up an individual. It’s like when Data from Star Trek – The Next Generation is processing something really intensively, like accessing the Borg Collective, his Positronic Neural Net starts blinking in patterns like crazy! I have seen in countless times when I have participated in Pair Programming. My partner will mention something it might only even be half related to the project we were currently working on, but I’ll scream, “I Got It!” and we talk out the idea together and quickly write out the code before either of us forgets it.
I highly recommend that if your managers approve of the practice, for younger developers to participate in Pair Programming.
And for more Senior Developers, working in Pairs with either another senior developer or even a junior developer, will help open your mind to new ideas when developing your critical components. The phrase “Two Minds Are Better Than One” really rings true here!
Pair Programming falls under the scope of Extreme Programming. Which is another great topic for discussion in another blog entry I’ll have to write…Just Another Stream of Random Bits… – Robert C. Ilardi