In pair programming do 2 develepers work on 1 task to finish it quicker with more quality

[Monica Shiralkar]

In pair programming 2 developers work on 1 tasks instead of individual tasks.This would mean say instead of 2 developers doing separate 8 hour tasks , they spend time on the same task. Although instead of 2 now 1 task will get accomplished ,is this done so that together they can do it faster and with better code quality ?
Thanks.

[Junilu Lacar]

Pairing is not a mechanical activity but rather a collaboration and conversation. The idea is to discuss what you're doing in real time from different perspectives: strategic and tactical. For example:

Navigator: We need to process all the items (high-level abstract strategic thinking)

Driver: Ok, I'll create a for-loop and pass each item to the processing method. I'll accumulate the results in this variable and maybe throw an exception if something goes wrong. (tactical thinking)

Navigator (reads the code the driver wrote): Yeah, that looks right.

[Monica Shiralkar]

In case of developers doing pair programming , I have a question.

Without pair programming , suppose developer X and Developer Y would have been working on Task 1 ans Task 2 today.

Now, with pair programming both spent their entire time today doing Task 1. So what have they achieved more than in the above case ? Is it improved quality, reduced rework , lesser time or any other benifit as compared to the above case ?

[Campbell Ritchie]

You are particularly trying to improve the quality of the code in its first pass.

[Les Morgan]

Monika,

I look at pair programming--I just call it collaboration--as getting the best from more than one source, resulting in getting a better product.

My very first programming job out of college required a certain task to be optimized.  They already had the processes to do the work, but they needed it faster.  I had what I thought was a brilliant idea, my coworker had what he thought a brilliant idea.  Turns out, what we each really had was a half assed idea that wasn't optimal, but together our ideas had a whole ass.

It was optimal.  How do it know it was optimal?  One of the leading consulting firms for our platform was given our solution because they made the comment that they would get it much faster.  After the analysis, they returned a report containing this line: "We cannot make it appreciably faster; in most cases anything we try results in taking longer."

During the evaluation my coworker called one of the consultants and asked what was going on.  his reply was this: "We gave it to a bunch of our jr engineers.  They think they found what makes the world go around."

collaboration, do not make the mistake of interpreting this as consensus, almost always, yields a better solution.

Have fun because life it too short not to,

Les

[Junilu Lacar]

Monica Shiralkar wrote:
Without pair programming , suppose developer X and Developer Y would have been working on Task 1 ans Task 2 today.

Now, with pair programming both spent their entire time today doing Task 1. So what have they achieved more than in the above case ? Is it improved quality, reduced rework , lesser time or any other benifit as compared to the above case ?

There are many tacit assumptions in what you've said there. I want to remind you again that programming is not a mechanical activity. It is not like putting Lego bricks together. Rather, you are creating software from ideas and there are an infinite number of ways you can put together ideas to create a program. Just try to write a Roman numeral conversion program for example. It's the same relatively simple requirements but there are many different ways to write it.

Without proper guidance and study, most people who try to do collaborative programming don't do it right. They will usually end up doing dictation, with the "navigator" dictating to the "driver" the exact code to write. This does not produce the same results as a truly collaborative effort where there is a sharing of ideas, a back and forth discussion, and a disciplined approach to making design decisions. When you say two developers work on tasks 1 and 2 separately but then they can only work on task 1 together then that tells me you're not thinking about the kind of collaborative dynamic that I've described. You're looking at it like programming is like building Legos.

When done effectively, collaborative development results in better quality code, tests, and a shared understanding between developers of how and why the code was written the way it was. You don't get these kind of benefits from solo programming.

When done ineffectively, (pseudo) "pair programming" is a waste of time and effort.

[fred rosenberger]

Let us also not forget the learning aspect. You can pair a junior and senior developer together. Or even a "database" person with a "GUI" person.  Both will learn from each other, and become better, more rounded developers.  Or a "business process" person with an "algorithms" person...And now you have TWO people who have worked on the code, both of whom have an understanding of it.  The next day, they can be paired with someone else and spread the knowledge further.

Another aspect that is occasionally forgotten is that there can be fewer distractions.  If i am in a cubicle by myself at work, I may think "oh, I'll look at www.coderanch.com for a few minutes and answer a question or two...", and then 30 minutes goes by while I type out some replies.  If I have someone in the cube with me, looking over my shoulder, i'm far less likely to do so.  Of course, depending on who my partner is that day, we might go off on a tangent discussing the latest Marvel movie, or SciFi TV show, or newest baking recipes...

There is a book by Fred Brooks called "The Mythical Man Month". It has many essays about programming, but the title refers to the concept that (people) x (hours) is linear - it's not always.  The classic example is "Nine women can't make a baby in one month".  On the other hand, sometimes talking through a problem sparks ideas.  I have often struggle with a problem for an hour (or more). Finally, I decide to go talk to a colleague.  I may not even get the problem halfway explained, when the solution pops into my head. Had that person and I been working together all along, talking through it, it's possible the solution comes in 10 minutes instead of an hour and ten minutes later.  Speaking engages a different part of your brain, allowing for other connections and leaps of logic to happen.

Is it guaranteed?  no.  Can pair programming be done wrong and slow things down? yes.  But if done right, it can be wonderful

[Monica Shiralkar]

Campbell Ritchie wrote:You are particularly trying to improve the quality of the code in its first pass.

Thanks. Yes, that will be improved this way.

[Monica Shiralkar]

Les Morgan wrote:Monika,

I look at pair programming--I just call it collaboration--as getting the best from more than one source, resulting in getting a better product.

Thanks

[Monica Shiralkar]

Junilu Lacar wrote:
When done effectively, collaborative development results in better quality code, tests, and a shared understanding between developers of how and why the code was written the way it was. .

Thanks. Yes, shared understanding in another benifit besides qlcode quality.

[Monica Shiralkar]

fred rosenberger wrote:Let us also not forget the learning aspect. You can pair a junior and senior developer together. Or even a "database" person with a "GUI" person.  Both will learn from each other, and become better, more rounded developers.  Or a "business process" person with an "algorithms" person...And now you have TWO people who have worked on the code, both of whom have an understanding of it.  The next day, they can be paired with someone else and spread the knowledge further.

Thanks. Yes this point is also important on the beinifts on pair programming.

[Monica Shiralkar]

I think if there is a senior programmer working with a fresher, the code quality would improve compared to the case of what the quality had been had only the fresher been working on it. But if you compare it to the case how the code quality would have been had the senior programmer been doing it alone ,then there may not be a difference in code quality.

[Junilu Lacar]

Monica Shiralkar wrote:if you compare it to the case how the code quality would have been had the senior programmer been doing it alone ,then there may not be a difference in code quality.

You are severely underestimating the value of collaboration and having shared understanding on a team even between just two people instead of one. Code quality is just a small piece of this.

[Les Morgan]

Monica,

the value of multiple minds, or, as the people I work with now call it: "eyes on the prize" is immensely more complicated then the assignment to code the problem or even that one person is senior and the other is junior.  When I read something, my mind edit's what I read according to my experience, tastes, and preferences.  Everyone does that.  Multiple eyes on the prize: gives the ability for multiple people to catch hold of what is being said: I hear what I want, you hear what you want, and others here what they want.  We collaborate and come to an understanding of what was truly said--we might even see that we need the job clarified before we can begin.

Once the understanding is there, then there is the formalization of the scope, what was said to be the deliverable--that is not always clear either--and multiple minds queuing off what was said in the ask, can be a good thing.  Then there is the actual design.  Please do not suppose that the senior has some magic bag they reach into and pull out the best possible every time--because thy do not (they may try to say they do, but watch; they do not)

What you seem to be implying, or at least what I am inferring from your remarks, is that the junior is going to be steam rollered and the senior is going to have most or all the input.  That truly is a sad development effort and a waste of time.  Multiple minds going at a problem from different angles usually leads to a much better solution--why do you think that think tanks use people from diverse experiences to attack a problem?  Because they don't want the cookie cutter solution, or maybe there isn't a solution and they need more than the tunnel vision of an individual.

If it comes down to coding it, you are given the use cases or whatever is used for the mockups and needs for the project and you are given your piece to code--that is "code monkey" work.  Little brain power needed.  Take the pattern and make it fit.  It's the design, powered by better understanding, which is enabled by that wider view afforded by multiple individuals that really makes the project better.

We have whiteboards in all of our offices, cubicles.  Each is not to doodle on, or to jot things down to not forget, although both of those happen, it is to write the multiple understandings of those discussing the problem.  I work with a really good team.  Any two of us may be talking and others will hear--they key in when they hear terms they are involved with, and will join in.  So now, instead of a SQL Developer and a front end programmer talking, there may be a DBA that can more full explain how what we are talking about is going to relate to the Db and the intricacies therein.  Or maybe one of the people that work on optimizations chimes in and suggests something. And so on....

If you are collaborating, then the solution really is better than any one in the project could have ever delivered.  Each person has to bring their skills to the table, sometimes that could be the different point of view that makes the difference, not really any experience in the field, but just how they see the world around themselves.  In any case, if the solution could be done by the senior, then the collaboration was a waste of time.

les

Monica Shiralkar wrote:I think if there is a senior programmer working with a fresher, the code quality would improve compared to the case of what the quality had been had only the fresher been working on it. But if you compare it to the case how the code quality would have been had the senior programmer been doing it alone ,then there may not be a difference in code quality.

[Monica Shiralkar]

Les Morgan wrote:
If you are collaborating, then the solution really is better than any one in the project could have ever delivered.

We have a task and an acceptance criteria.It has to be done exactly that way.
By better code what I understand is that although it will do the same thing as it was supposed to be done (as per the acceptance criteria), it would have fewer bugs. Is that all ?