In pair programming do 2 developers 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 ?

[Paul Clapham]

Monica Shiralkar wrote:[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 ?

You must be one of those managers for who producing code as fast as possible is the one and only goal of the enterprise. The idea that with two programmers, one of them can point out a better way to the other which might have been missed; or the idea that after the code is finished you have two programmers who know something about the code instead of one; are those worthless goals for you?

[Monica Shiralkar]

Paul Clapham wrote:

The idea that with two programmers, one of them can point out a better way to the other which might have been missed;

Yes, and that's why I had said "lesser bugs".

[Monica Shiralkar]

Paul Clapham wrote: the idea that after the code is finished you have two programmers who know something about the code instead of one

Thanks. Yes, definately.

[Monica Shiralkar]

Paul Clapham wrote:. The idea that with two programmers, one of them can point out a better way to the other which might have been missed; or the idea that after the code is finished you have two programmers who know something about the code instead of one;

The latter looks a bigger advantage to me of pair programming than the former.

[Paul Clapham]

And the senior programmer might point out to the junior programmer that, instead of writing 20 lines of code to do some particular thing, they could call a method in some other class which already does that thing. Thereby reducing duplicate code with all of the possible errors it might contain. The list of possible advantages goes on...

[Paul Clapham]

Monica Shiralkar wrote:The latter looks a bigger advantage to me of pair programming than the former.

You asked for advantages. Ranking them against each other is just being snarky.

[Monica Shiralkar]

Paul Clapham wrote:And the senior programmer might point out to the junior programmer that, instead of writing 20 lines of code to do some particular thing, they could call a method in some other class which already does that thing.

Yes

[Dave Tolls]

Monica Shiralkar wrote:

Paul Clapham wrote:

The idea that with two programmers, one of them can point out a better way to the other which might have been missed;

Yes, and that's why I had said "lesser bugs".

I've found it's not so much about bugs (if only because I would hope some form of test driven dev was at work), but maintainability.
Writing by myself any code makes perfect sense...funnily enough that's not always the case when someone else has to work with that code.
Pairing helps to produce code that is more likely to make sense to more people.

That's my experience anyway.

[Junilu Lacar]

Regarding maintainability, I tell people to ask these questions:
1. Do we understand it the same way?
2. Will other people understand it the same way?
3. Will we still understand it the same way the next time we work with this code?

It takes practice to be able to answer "No" to any of these questions but when you do and can refactor the code enough to say "Yes" then you know your collaboration has been of value.

[Monica Shiralkar]

Dave Tolls wrote:
Writing by myself any code makes perfect sense...funnily enough that's not always the case when someone else has to work with that code.
Pairing helps to produce code that is more likely to make sense to more people.

But aren't good developers already writing such code without depending upon any pair programming ?

[Al Hobbs]

I think pair programming would be ideally used to help junior developers.  The only time senior developers would do that is for fun or they have a long time to finish.  Two developers doing pair programming makes development slower than one developer alone.

[Dave Tolls]

Monica Shiralkar wrote:

But aren't good developers already writing such code without depending upon any pair programming ?

We all suffer from code blindness, whether it is not spotting a bug that turns out to be obvious to another dev, or whether it is a blindness to a hidden complexity in something we've written.
We make assumptions, one of which tends to be that we know what we're doing and it all makes sense.

Pair programming helps to mitigate that, so long as it's actual pairing and not just driver/navigator as I think has been mentioned above.

Proper reviewing helps as well...again so long as it's proper reviewing and not just "the tests run so it's all OK".

[Junilu Lacar]

Al Hobbs wrote:I think pair programming would be ideally used to help junior developers.  The only time senior developers would do that is for fun or they have a long time to finish.  Two developers doing pair programming makes development slower than one developer alone.

There are shops that won't put any code in production unless it has been done by at least a pair. Others will only write production code as a mob. Clearly these shops don't operate the way you describe.

Accounting for time by considering only what is spent during initial development is myopic. The savings comes in the long term, where other people don't waste time scratching their heads because they don't understand the code, where features can be easily added because the design is well factored, and defects are few and easy to find and fix. Generally, the overall cost of ownership is lower when code is produced collaboratively.

The assumption, of course, is that pairing/mobbing results in better refactoring of code, better testing, better design, all because the developers invested time in collaborating and having a shared understanding of the problem and the solution.

This is something that people who have never experienced it find hard to understand or even believe. Unfortunately, many try pairing/mobbing without the prerequisite skills in refactoring, design, and testing, or understanding of how the collaboration should flow so they miss out on the benefits and carry on believing that it's a waste of time.

[Junilu Lacar]

Al Hobbs wrote:I think pair programming would be ideally used to help junior developers.  The only time senior developers would do that is for fun or they have a long time to finish.  Two developers doing pair programming makes development slower than one developer alone.

Senior-to-senior developer pairing is actually more common than you think. It's not just fun but also very effective. Again, you really have to experience it to understand.

[Monica Shiralkar]

What I understand is it should not become a habbit for any developer that when I do pair programming my other developer pairing with me makes sure that we are doing it correctly and later when I am doing it alone (without pair programming ) I do mistakes because there is no other developer paried with me now who would have ensured that we do it correctly.

Also I feel pair programming would be more beneficial in product based companies than in the service industry.

[Jeanne Boyarsky]

Monica,
It doesn't mean you rely on the other person. It means that two people are more likely to spot errors. In fact even the person typing is less likely to make errors because there is communication and explaining.\

I pair at work sometimes. It isn't a crutch when I'm not pairing.

[Paul Clapham]

Monica Shiralkar wrote:Also I feel pair programming would be more beneficial in product based companies than in the service industry.

I don't know what you mean by "product-based company" and "service industry". Could you explain the difference? And then it would be interesting to hear why you think pair-programming is more beneficial to one rather than the other.

(I worked for many years for a wholesaler. The company bought large quantities of products from manufacturers, then sold small quantities of those products to retail stores. This process is clearly a service and it's clearly product-based.)

[Junilu Lacar]

Monica Shiralkar wrote:What I understand is it should not become a habbit for any developer that when I do pair programming my other developer pairing with me makes sure that we are doing it correctly and later when I am doing it alone (without pair programming ) I do mistakes because there is no other developer paried with me now who would have ensured that we do it correctly.

Collaborative practices like pairing/mobbing are enabling and enhancing techniques. They encourage certain ways of thinking that most developers find difficult to follow when they are working solo. With practice (lots of it), you can train to think in the same way even when you are working solo. I have done that. However, you still miss out on the different perspectives other people bring to the conversation.

I'm not sure when you say "doing it correctly" that you mean it in the same way that I mean it. For me, doing pairing/mobbing correctly is not about producing correct code, i.e. code that does what it's supposed to do. Doing pairing/mobbing correctly is about have a conversation that flows the right way, in a way that produces shared understanding of the problem, the design, and how the resulting program that embodies the solution came to be.

A skilled solo programmer can write well-factored and expressive code, sometimes even better that what a pair or mob might produce. However, in my experience there aren't very many programmers like that out there. Most programmers would do better working in a pair or mob. All programmers can benefit from pairing/mobbing if they would only spend some time trying to learn and do it properly.

The next time you spend ten minutes trying to understand a piece of code, know that it's basically because the code doesn't help you understand what the heck the original author of the code was thinking. This is the kind of wasted time that you save yourself and others from when code is expressive. well-factored, and easy to understand because it was written by a pair or mob or by someone who was thinking in the way a pair or mob would be collectively thinking.

[Junilu Lacar]

Let me elaborate on what I mean by "enabling and enhancing."

Previously, I noted three questions I tell people to ask as they're pairing/mobbing. Those can be rephrased as:
1. Do we understand this code the same way? Alternatively, This is how I understand it: (explain). Is that how you understand it?
2. Will someone else reading this code understand it the same way?
3. Will we be able to understand this code when we read it again later (in a few days, weeks, or months)?

Other questions we ask that are related to the above:
1. What do we really mean by this?
2. What is the intent here?
3. What term is usually associated with this concept?
4. How does this thing here related to that other thing? Does the code make that relationship apparent or intuitive?
5. What test scenario relates to this functionality?
6. Does the test represent a good example of how this code should be used?

Think about the last time you wrote code solo. Did you even ask yourself any of these kinds of questions? If not, then that's what you're missing out on by not pairing and mobbing. Usually, when programmers are working solo, their main focus is implementation and they can't easily switch back and forth between the strategic (high-level abstract) and tactical (implementation details) modes of thinking.

Even in pairing and mobbing situations, I often have to remind people to pull their heads out of the tactical mode and think about intent and expressing that intent clearly. I often have to remind people to write a test that expresses what the behavior should be. I often have to remind people to refactor, to actively look for code smells. If a pair/mob can still miss these things then the likelihood of a solo developer missing them is even higher. Pairing/mobbing enables/enhances our ability to produce code using both strategic and tactical modes of thinking. Solo programming, not as much.

[salvin francis]

For having a question mentioned in the January 2021 CodeRanch Journal, congratulations: this question earns you a cow

[Monica Shiralkar]

Jeanne Boyarsky wrote:Monica,
It doesn't mean you rely on the other person. It means that two people are more likely to spot errors. In fact even the person typing is less likely to make errors because there is communication and explaining.

Yes. Agreed.

[Monica Shiralkar]

Paul Clapham wrote:
I don't know what you mean by "product-based company" and "service industry". Could you explain the difference? And then it would be interesting to hear why you think pair-programming is more beneficial to one rather than the other.

What I understand is that product based companies are the ones where first a software is developed and then client is searched who will buy this .Service based companies are the ones where software is developed for a client as per the features and specifications he wants.I thought that in case of product based if two delevopers are discussing they may even come up with ideas on what better things they can add to the product .In service based it has to be done exactly as the customer wanted.

[Monica Shiralkar]

salvin francis wrote:For having a question mentioned in the January 2021 CodeRanch Journal, congratulations: this question earns you a cow

Thanks

[Monica Shiralkar]

Junilu Lacar wrote:

A skilled solo programmer can write well-factored and expressive code, sometimes even better that what a pair or mob might produce. However, in my experience there aren't very many programmers like that out there. Most programmers would do better working in a pair or mob. All programmers can benefit from pairing/mobbing if they would only spend some time trying to learn and do it properly.

Yes. That's true.

[Monica Shiralkar]

Junilu Lacar wrote: Usually, when programmers are working solo, their main focus is implementation and they can't easily switch back and forth between the strategic (high-level abstract) and tactical (implementation details) modes of thinking.

Thanks.Yes. That's the difference.