Hi,
After the excellent Coding Dojo with the help of Luis Ruiz Pavón we did with the guys from MadridDotNet, because I was pending to explain mathematical because it is useful to make a practice of Pair Programming in development teams. Pair Programming or programming pair defines a scenario where program is basically a two. Here’s the definition from Wikipedia:
Pair programming (or Pair Programming in English) requires two Software engineers to participate in a combined effort of developing a job site. Each Member performs an action that the other is not currently doing: while one encodes units tests the other thinks in the class that will satisfy the test, for example.
The person is doing coding is given the name of controller while the person who is leading is called the browser. It often suggests that two partners at least every half hour change roles or after becomes a unit test.
This practice is quite useful, has many detractors because usually people think that the world of development 4 hands produce more than 2. When in reality 2 heads produce much more than a single. But well, if once you’ve found with a "head" condemn this philosophy of work, this exercise can help you to demonstrate because a practice of Pair Programming is really useful.
Ideal scenario
Suppose we have a team of 6 people consisting of 2 programmers seniors and juniors 4 programmers. In an ideal scenario of working, we can assume that a senior programmer on a daily basis pays an amount of 2 units of work (UT), while a Junior programmer pays 1 UT. If we have a 5 day standard work week because at the end of the week we will have 40 UTs. The following table shows these numbers to make them clearer
| Team |
Día 1 |
Día 2 |
Día 3 |
Día 4 |
Día 5 |
Total |
| SrP |
2 |
2 |
2 |
2 |
2 |
10 |
| JrP |
1 |
1 |
1 |
1 |
1 |
5 |
| JrP |
1 |
1 |
1 |
1 |
1 |
5 |
| SrP |
2 |
2 |
2 |
2 |
2 |
10 |
| JrP |
1 |
1 |
1 |
1 |
1 |
5 |
| JrP |
1 |
1 |
1 |
1 |
1 |
5 |
| |
|
|
|
|
|
40 |
Real scenario
But of course, if you actually do software development and are aware of what does your team know that day maybe a Sr Programmer can give 100% and generate their 2 UT, but the next few days will have to help the Junior Programmers to close his work. Often this means that their personal performance will drop to the floor and will be devoted to work by 2 or 3 to be able to take work forward. Being generous with the cast of UTs, this scenario could look like the following table.
| Team |
Día 1 |
Día 2 |
Día 3 |
Día 4 |
Día 5 |
Total |
| SrP |
2 |
|
|
|
|
2 |
| JrP |
|
1 |
|
1 |
1 |
3 |
| JrP |
|
|
1 |
|
1 |
2 |
| SrP |
2 |
|
|
|
|
2 |
| JrP |
|
1 |
|
1 |
1 |
3 |
| JrP |
|
|
1 |
|
1 |
2 |
| |
|
|
|
|
|
14 |
Before moving to the next stage, and that you’ve read here, ask you because it is so frequent that developers gather together among themselves to discuss a topic in particular or to show portions of code. You’ll see that many times are doing programming in pairs without even knowing it.
Finally let’s see what would happen if we put together a SrP and a JrP; and we let the 3rd pair of JrP will rotate with previous. Since being very amarrete with the UTs, input we already have almost 150% more than in the real scene. And of course, assuming that the JrP can not pay more with the passage of time. The following table shows this example:
| Team |
Día 1 |
Día 2 |
Día 3 |
Día 4 |
Día 5 |
Total |
| SrP |
|
|
|
|
|
0 |
| JrP |
1,5 |
1,5 |
1,5 |
1,5 |
1,5 |
7,5 |
| JrP |
|
|
|
|
|
0 |
| SrP |
1,5 |
1,5 |
1,5 |
1,5 |
1,5 |
7,5 |
| JrP |
|
|
|
|
|
0 |
| JrP |
1 |
1 |
1 |
1 |
1 |
5 |
| |
|
|
|
|
|
20 |
Well, here you have an example completely unrealistic about how Pair Programming can help us improve the performance of our teams. Obviously that I post here is a real study nor true, since that software development is affected by many other variables; but perhaps if you together with a blunt head you can start to do recognize that you working in the stage 2 and then explain the scenario 3 is better.
Done the friki stuff ot the week … 
Update: I’ll put a bit of context to explain why this entry and why do not you should take seriously, is simply an exercise to demonstrate that YOU CANT put down to simple numbers the work of a team. Pair Programming is a practice that has many advantages, if you want to know because your friend google or his friend Bing, can help you. But I will recommend The Agile Samurai, a book mandatory for these days. In this particular case I have destroyed all good project management practices to reach a number that is valid for the post, for example
- It is impossible to measure the working capacity of a person in "work units", everyone knows that the work of a developer is measured on the basis of the number of lines of code that writes per day. If you don’t know how to do it, this post can help you identify who works and who not.
- Pair Programming is not based on join a Senior Programmer and a Junior programmer, is a little more complicated. I personally recommend make couples on the basis of the years of each person. Is scientifically demonstrated that when the sum of the years of a couple is an exact multiple of 3 or 7, performance increases in a 18%
- Pair Programming allows us to save hardware costs. No need 2 computers, we can reduce IT costs by half. Another thing that I recommend to save costs and space to work with programming in pairs, is not have 2 chairs, but a single chair and a person hung in Mission impossible. This also helps if it hangs with a slight inclination downward, will get more blood to your head and you can write more lines of code to the day
Greetings @ Home
El Bruno
Sources: http://es.wikipedia.org/wiki/Programaci%C3%B3n_en_pareja
Rather than identify a color as in the array that returns the camera.
. We’ll see topics as diverse as Silverlight, ASP..NET, Ajax, JQuery, TDD, 
