Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in.[i] Pair programming is considered a wasteful technique because people tend to believe that navigators aren’t writing code. In fact, this simplistic view lays on the foundation that the more people writing code, the faster you product will release. Yet, things usually go even worse because products suffer from maintainability and complexity problems in short and long run as a result of poor software development practices, inexperienced teams and occasional quality reviews. Some studies have shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs[ii]. I decided to give it a try when I came across queuing theory, which is a statistics and probabilistic approach to evaluate how systems (teams) perform when jobs are nonrepetitive, nonhomogeneous and they arrive in an unpredictable arrival rate. It sounds familiar!!!!. Isn’t it? Some additional concepts are needed before continuing: Server(s) are the resources whom perform the job. Arrival process describes the arrival pattern to the queue. Service process is the amount of time that it takes to accomplish the work. Queuing discipline describes how we manage the arrival work (FIFO First input first output, LIFO last input, first output,etc)
Next chart depicts the relation between capacity utilization and service process for a system with unpredictable arrival rate and unpredictable service time, also defined as M/M/1/∞
Notice that cycle time increases exponentially as you increase capacity utilization thus, the effect of overloading teams drives to blocking system’s workflow more and more. So, the effect of loading systems from 70% to 80% capacity utilization increases cycle time around 25 times.
What should we do to keep capacity utilization under certain limits? My favorite choice is limiting WIP. Another valuable countermeasure is the pair programming technique because it helps decrease the team’s capacity utilization to acceptable levels (behind the scenes) which also leads to reduce cycle time and to improve flow. This technique also strives to reduce silo mentality, promoting code ownership through the constant rotation of pairs. Again, queuing theory confirms that mathematically systems perform better when there’s only one queue (product backlog) and several servers (team members) whom can deal with work.
Thus, if your goal is to increase system’s performance, you should try to seed and promote T shape servers. Those whom are experts in a single area and should potentially develop abilities to collaborate with other areas. Finally, a fow more benefits from the pair programming practice: developers learn from each other new development skills and continuous rotation creates a strong sense of “team”.