Jump to content

  • Log In with Google      Sign In   
  • Create Account

Pair Programming Revisited


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
10 replies to this topic

#1 Memir   Members   -  Reputation: 129

Like
1Likes
Like

Posted 19 March 2014 - 04:48 PM

So a little background about me. I've been developing software in the back bedroom for many years, along with my brothers. Worked for a dozen different companies in varied team sizes, on many successful projects over the past 8 years. So I would consider myself pretty experienced (Games, Applications, Web Applications, C++/Assembly/Flash/PHP etc. you get the idea).

 

So now, on my most recent contract. The most highest paying one I've ever had, a very important UK project, but arguably one of the more easier projects I've been involved with, and working alongside generally less talented developers than most of my previous roles. I've come across this new buzz word called "Pair Programming" (PP).

 

Now I'm not sure how I've managed to avoid PP for so long in my career. But apparently, PP is not only the solution to improving code quality, but is apparently the only way any good software was ever built, and any project that has been successfully developed without PP is a miracle.

 

(I personally think considering the importance of the project we're working on. We should take the hiring process more seriously and hire quality developers i.e. nerds. over hiring 'politically savvy' sub-standard developers and coming up with various processes to improve their output on such an important project.)

 

*end of rant*

 

Now looking at this objectively. If I do a google search for PP. I can see a lot of studies that report PP to be more productive, improve code quality, and reduce bugs. I can't understand this when most programming tasks are trivial (or at least seem trivial to me). Once the architectural aspects of a task have been discussed. A good programmer should be competent enough to implement the architectural specification. Then once implemented, another developer should be able to code-review it, just to pick up any small programming mistakes (not architectural mistakes as that has been cemented before coding).

 

Looking back on an old topic on GameDev.net about PP, seems mostly negative views on it. Perhaps GameDev.net developers have a different view, or perhaps the majority of developers have a different view, and these studies are skewed?

 

I think the problem is that in most projects. There are 10-20% of programmers that are truly talented and motivated. They are responsible for the core, and even much of the bulk of any software project. The other 80-90% lack talent and/or motivation and don't contribute much (especially when you factor in the number of bugs, and hacks they introduce). PP works well for them.

 

"I find with PP I'm much more productive" - Perhaps thats because when you work alone, you're not focused, and browse the internet most of the time. Or perhaps thats because you're not as good as your pair, so your output is being raised (perhaps your "better-half" is less productive - assuming he is motivated on his own).

 

"I find with PP we spot errors like semicolons, and brackets more quickly" - Missing semicolons and brackets is simply unacceptable. If you make these silly mistakes shame on you. If it takes you a long time to spot them after the compiler has helped you find the line, then well I think you need to find new profession.

 

"I find with PP we come up with different solutions to solve a problem" - No, discussing how you're going to tackle a task gives you different solutions to solve a problem, this is architectural design. If you have discussed a problem properly before writing a single line of code. Then there are very few ways of implementing the code, especially once you follow an agreed upon coding standard/convention.

 

"I find with PP I learn lots" - You can also learn a lot just by reading or reviewing the code, instead of interrupting someone's train of thought. I actually find I learn much better by playing with the code, figuring out how things work and developing a complete map of the code base, instead of relying on someone else to tell me all the answers.

 

"After a long day with PP I feel satisfied" - This is very interesting. Considering programmers tend to be introverted. I find programming solo, very therapeutic, and I can code into the evening with people reminding me to go home. Makes you feel pumped and really good about yourself. With PP, I start to get a headache in the afternoon, and just want to go home. It's painful, emotionally draining. - I don't consider myself that introverted, I enjoy talking to people, helping them with problems, and chatting up the female staff. I just don't enjoy pair programming. I feel like an impatient kid jumping up and down watching a programmer slowly write code, and constantly correcting them, and trying to convince them to do it my way.

 

It probably is a case of talent and motivation. I've done a lot of pairing with others over the past 6 months. But when I think of all the times when I've paired with other people. I've felt that it would've been of better quality on my own (they disregarded certain safer techniques that I would've used), and done quicker (they seemed tired, and not properly focused). While they felt that they produced better quality code with me, and that they were productive.

 

(Weak Programmer + Good Programmer) / 2 = Average Programmer.

(Lazy Programmer + Motivated Programmer) / 2 = Average Programmer.

 

In closing. I have a habit of checking the git blame (or svn annotate) whenever I see some pathetic excuse for code (dirty copy and paste, badly named variables, not following code conventions, lazy hacks etc.). So I can tell the programmer what I think of his work. However, many a time, I've done this, and to my surprise I discover that the work was paired on (in the comments we mention the initials of who we paired with on the task). So I'm not convinced that pairing is the solution to improving code quality. Finding decent programmers is the best solution (which requires a combination of good pay, and more importantly good interview and selection process). Perhaps our education system is swamping the software industry (especially big companies) with graduate programmers who are neither motivated or up to the standards of the older generation of back-bedroom programmers.

 

It could also be that I'm not much of a team player :D - Although I actually enjoy discussing and planning things with others. I'm just old fashioned in that I like to do the work on my own.

 

Coming soon: Quad programming, the only way real software is made.

("We tried making a hello world program, and were scratching our heads trying to find out why it wouldn't compile. My number 2 couldn't smell it. Number 3 suggested reading the error message, thats what his iPhone says. Number 4 guessed it was a pesky semi colon...")


Flash Pool - Pool/Billiards game for Facebook (developed by Memir).

Sponsor:

#2 Olof Hedman   Crossbones+   -  Reputation: 2826

Like
1Likes
Like

Posted 19 March 2014 - 05:13 PM

Nice wall of text :)

 

Well, I can agree, I'm also not very fond of pair programming...

I kind of think in code, and more visually then in words, and I need to write it while thinking... And evolve it until it solves the problem.

Discussing it at the same time just slows me down.

 

I'm glad to help my peers with details if they ask me, but I find that the times I've tried actual PP its not long before I grab my laptop so we can write some code in parallel.

That can be good though, but there need to be enough of a problem that there need to be some architectural discussion or something else that actually need two people two solve...

 

It can be helpful with two pairs of eyes and some discussion, when researching really nasty bugs though.

But only for a limited time :)



#3 L. Spiro   Crossbones+   -  Reputation: 13600

Like
4Likes
Like

Posted 19 March 2014 - 05:42 PM

Pair-programming is effective primarily when used with foresight in a per-case situation.

There are times when I work best alone, as should be true for all of us over half the time to varying degrees.

But in some cases I need to implement an algorithm into an existing code base and I am not very familiar with the code.  Pairing up with someone who knows the code base is quite efficient.

 

I explain and code the algorithm or feature while asking, “Now I need the part of the code that handles this,” and he or she quickly directs me there, explaining any caveats I need to know before proceeding.

 

 

As with most things, it’s usually only “purely bad” because it is not being used properly.  If utilized correctly it does have a good side.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#4 SimonForsman   Crossbones+   -  Reputation: 6111

Like
4Likes
Like

Posted 19 March 2014 - 05:44 PM

So a little background about me. I've been developing software in the back bedroom for many years, along with my brothers. Worked for a dozen different companies in varied team sizes, on many successful projects over the past 8 years. So I would consider myself pretty experienced (Games, Applications, Web Applications, C++/Assembly/Flash/PHP etc. you get the idea).

 

So now, on my most recent contract. The most highest paying one I've ever had, a very important UK project, but arguably one of the more easier projects I've been involved with, and working alongside generally less talented developers than most of my previous roles. I've come across this new buzz word called "Pair Programming" (PP).

 

Now I'm not sure how I've managed to avoid PP for so long in my career. But apparently, PP is not only the solution to improving code quality, but is apparently the only way any good software was ever built, and any project that has been successfully developed without PP is a miracle.

 

(I personally think considering the importance of the project we're working on. We should take the hiring process more seriously and hire quality developers i.e. nerds. over hiring 'politically savvy' sub-standard developers and coming up with various processes to improve their output on such an important project.)

 

*end of rant*

 

Now looking at this objectively. If I do a google search for PP. I can see a lot of studies that report PP to be more productive, improve code quality, and reduce bugs. I can't understand this when most programming tasks are trivial (or at least seem trivial to me). Once the architectural aspects of a task have been discussed. A good programmer should be competent enough to implement the architectural specification. Then once implemented, another developer should be able to code-review it, just to pick up any small programming mistakes (not architectural mistakes as that has been cemented before coding).

 

Looking back on an old topic on GameDev.net about PP, seems mostly negative views on it. Perhaps GameDev.net developers have a different view, or perhaps the majority of developers have a different view, and these studies are skewed?

 

I think the problem is that in most projects. There are 10-20% of programmers that are truly talented and motivated. They are responsible for the core, and even much of the bulk of any software project. The other 80-90% lack talent and/or motivation and don't contribute much (especially when you factor in the number of bugs, and hacks they introduce). PP works well for them.

 

"I find with PP I'm much more productive" - Perhaps thats because when you work alone, you're not focused, and browse the internet most of the time. Or perhaps thats because you're not as good as your pair, so your output is being raised (perhaps your "better-half" is less productive - assuming he is motivated on his own).

 

"I find with PP we spot errors like semicolons, and brackets more quickly" - Missing semicolons and brackets is simply unacceptable. If you make these silly mistakes shame on you. If it takes you a long time to spot them after the compiler has helped you find the line, then well I think you need to find new profession.

 

"I find with PP we come up with different solutions to solve a problem" - No, discussing how you're going to tackle a task gives you different solutions to solve a problem, this is architectural design. If you have discussed a problem properly before writing a single line of code. Then there are very few ways of implementing the code, especially once you follow an agreed upon coding standard/convention.

 

"I find with PP I learn lots" - You can also learn a lot just by reading or reviewing the code, instead of interrupting someone's train of thought. I actually find I learn much better by playing with the code, figuring out how things work and developing a complete map of the code base, instead of relying on someone else to tell me all the answers.

 

"After a long day with PP I feel satisfied" - This is very interesting. Considering programmers tend to be introverted. I find programming solo, very therapeutic, and I can code into the evening with people reminding me to go home. Makes you feel pumped and really good about yourself. With PP, I start to get a headache in the afternoon, and just want to go home. It's painful, emotionally draining. - I don't consider myself that introverted, I enjoy talking to people, helping them with problems, and chatting up the female staff. I just don't enjoy pair programming. I feel like an impatient kid jumping up and down watching a programmer slowly write code, and constantly correcting them, and trying to convince them to do it my way.

 

It probably is a case of talent and motivation. I've done a lot of pairing with others over the past 6 months. But when I think of all the times when I've paired with other people. I've felt that it would've been of better quality on my own (they disregarded certain safer techniques that I would've used), and done quicker (they seemed tired, and not properly focused). While they felt that they produced better quality code with me, and that they were productive.

 

(Weak Programmer + Good Programmer) / 2 = Average Programmer.

(Lazy Programmer + Motivated Programmer) / 2 = Average Programmer.

 

In closing. I have a habit of checking the git blame (or svn annotate) whenever I see some pathetic excuse for code (dirty copy and paste, badly named variables, not following code conventions, lazy hacks etc.). So I can tell the programmer what I think of his work. However, many a time, I've done this, and to my surprise I discover that the work was paired on (in the comments we mention the initials of who we paired with on the task). So I'm not convinced that pairing is the solution to improving code quality. Finding decent programmers is the best solution (which requires a combination of good pay, and more importantly good interview and selection process). Perhaps our education system is swamping the software industry (especially big companies) with graduate programmers who are neither motivated or up to the standards of the older generation of back-bedroom programmers.

 

It could also be that I'm not much of a team player biggrin.png - Although I actually enjoy discussing and planning things with others. I'm just old fashioned in that I like to do the work on my own.

 

Coming soon: Quad programming, the only way real software is made.

("We tried making a hello world program, and were scratching our heads trying to find out why it wouldn't compile. My number 2 couldn't smell it. Number 3 suggested reading the error message, thats what his iPhone says. Number 4 guessed it was a pesky semi colon...")

 

You are forgetting a few things though, less experienced programmers learn alot while paired up with a more experienced developer and the experienced developer will improve his teaching skills at the same time (This is very valuable to a company in the long run), On large complex projects it is very hard for any single developer to be an expert on everything (and even if you have a company filled with übergodprogrammergurus they still won't be familiar with every part of a large codebase), pairing helps spread knowledge within the company. If the programmer who wrote your <insert component or system here> gets sick, quits etc. it really helps to have other people in the company who are familiar with the work he has done.

 

Pair programming isn't primarily for your benefit or your partners benefit, it is for your employers benefit.


Edited by SimonForsman, 19 March 2014 - 05:47 PM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#5 frob   Moderators   -  Reputation: 21323

Like
3Likes
Like

Posted 19 March 2014 - 07:10 PM

It was popular in many businesses for a very short time about 15 years ago.

 

IIRC the results went like this:

 

novice/novice = moderately slower than one novice alone, significantly fewer bugs, some learning occurs. Near neutral as it is training.

expert/novice = similar time to a novice, significantly fewer bugs, much learning occurs. Net gain if we are training.

expert/expert = moderately slower than one expert, slight reduction in bugs, little learning occurs. Net loss.

 

When mentoring a novice it can be useful for the educational perspective. Otherwise in a professional environment where everyone is expert it just adds costs.

 

HOWEVER...

 

In some industries it can make much more sense.

 

We don't usually worry about defects in games. In games the cost of a failure is normally very small. Errors are common, they are caught in QA, and if they ship to the customer there is a chance a patch will be issued, but probably not.  Simple buddy-checks are not quite as comprehensive as paired programming, and they accomplish most of the goals with very little effort.

 

For another industry, consider how every few years before and after certain events the old Voyager probe programmers remotely update the software.  You can be certain that many programmers are involved in verifying every detail, simulations get run, and people do everything possible to prevent turning the probe into a floating brick.

 

I have had co-workers who worked in military simulations, as well as friends who still do. For modifications to military equipment on the field they must figure out every change, do a bunch of paperwork documenting the change, the effects of the change, the results of the change, the testing that will be required to recertify the code after the change. Then after the bureaucracy churns for some time, they are either granted or denied permission to make the change.


Check out my personal indie blog at bryanwagstaff.com.

#6 Memir   Members   -  Reputation: 129

Like
1Likes
Like

Posted 22 March 2014 - 05:35 AM

Thanks for the responses. I would like to apologise for the wall of text in the original post. I wanted to rant, but also focus on making mostly objective. But alas I'm very passionate about programming, software and especially the currently project I'm working on, and got a bit carried away.

 

Yes, I think the problem with our project is that the chief proponents of pair-programming are the Scrum Masters (who have no technical experience, and zero programming experience). I feel that many of the developers are political brown-nosers, and don't really care about the project beyond following the Agile process & whatever the mighty Scrum Masters decide (as they are responsible for the hiring & firing).

 

They are suggesting that we should all pair 100% of the time during a sprint. I feel this is simply not practical, and is a massive waste of resources. Most programming isn't rocket science, and companies should be hiring people that are qualified to write decent code. This latter point I think is the problem.

 

The only real benefit I can see from pair programming (that can't be gained so well from code-reviews, and just calling someone over 5-10 mins to explain something to you), is that of training/mentoring someone less experienced. For this, it must be established before pairing, not who is the Driver & who is the Navigator. But who is the Student, and who is the Teacher.

 

I simply feel, and I may be wrong. I'm just the 'programmer' after all, no one tells me the big picture. That if you have a project which is so important, which you simply cannot afford to mess up. You shouldn't focus your efforts on training graduates, leave that for another team. You should be hiring the best in the industry, and let them focus on priority number 1, which is delivering a kickass product!

 

I find I can just read code to learn new ideas and approaches to problems. Only thing I learn from pairing with someone else is: How fast they type, what keyboard short-cuts they use/don't use, how often they are distracted, their thought processes. If I were the project manager, then it might be useful, as I could find out who were the effective programmers and who were not. But I could just review all the patches submitted over a period of say a week to see how much work people were doing, and the quality/complexity of the work. (unfortunately our Scrum Masters are clueless to the output of their workers, if they knew, they would almost certainly abandon Pair Programming).

 

---

 

In terms of gains to the employer. This is another interesting topic. The question over is it better to have everyone working on everything. Or people that specialise on certain components...

 

With the former: The advantage is that everyone knows a little bit about everything.

With the latter: The advantage is that everything has someone who is an expert.

 

From my experience, and my current employer has also come to the conclusion that the latter is far more beneficial.

 

In theory it's good for everyone to know about everything in case someone is busy on something else, away, or leaves the company. However, in practice this is rare. You might lose an expert every 6-12 months, depends really on the project. - I think a lot of developers leave projects because they have no attachment to it. They don't feel they own anything in the cluster-**** of components.

 

In practice what happens is that no one knows enough about any single component to be confident enough to know what will happen if you do this or that. No one has a complete mental map of any component. You can't properly work on a component, without knowing what *EVERY* line of code inside that component does. Sure you can add an extra function here, or a little bug fix there, achieving a task now. But what happens is that over time, there are lots of ugly extensions, hacks, and bug fixes, that makes the code unmaintainable, because no one can see enough of the forest to say "Hey there is already a SetTextToRed written by Jim, SetTextToGreen written by Jack, and I'm writing a SetTextToBlue function, why not just have a SetTextColor function" - of course that's a simple and obvious refactor that anyone should see, in practice they're a bit more complex than that. But these are the things that are missed when you have no component ownership.

 

The most bug-riddled code is in the code which is old, has had a lot of modifications over time, and has been worked on by a lot of people. I love git-blame, it tells an amazing story about the code you're looking at.


Flash Pool - Pool/Billiards game for Facebook (developed by Memir).

#7 frob   Moderators   -  Reputation: 21323

Like
4Likes
Like

Posted 23 March 2014 - 09:41 PM

Yes, I think the problem with our project is that the chief proponents of pair-programming are the Scrum Masters (who have no technical experience, and zero programming experience). I feel that many of the developers are political brown-nosers, and don't really care about the project beyond following the Agile process & whatever the mighty Scrum Masters decide (as they are responsible for the hiring & firing).

Perhaps that is true where you are.

The term "scrum master" was not originally an alternate title for "project manager". Before Agile became a buzzword the job fell to one of the non-manager leads. When it became a buzzword many project managers said "Let's have scrum, I'll be in charge." The best places and projects I have worked on put the job on the highest non-manager technical individuals, sometimes rotating through them every few months.

For the "political brown-nosers", sounds like an issue either with you or with them. Possibly it is with you, since you are interpreting their actions by your own perceptions. You could be wrong. Or maybe you are right, perhaps it is a problem of that specific workplace. Either way, the only person you can change is yourself. I suggest you properly diagnose the issue, since if the problem is on your end it will just follow you between jobs.

They are suggesting that we should all pair 100% of the time during a sprint. I feel this is simply not practical, and is a massive waste of resources. ... additional ranting...

Remember the golden rule; those with the gold make the rules.

The boss wants you to do it, and the boss is writing the checks. You can decide either to do what they want and accept the money, or not. If you disagree with the boss, you might consider tactfully discussing it with them.

You have a large rant. You might be right, the entire system might be corrupt and everybody might be in on it. Alternatively, it could be that you are missing important information.

Based on the rant, I am guessing there is a problem at your workplace. The bosses feel this might help. Paired programming can help with training. Paired programming can help with motivation. Paired programming can help form team bonds. Paired programming can help eliminate bad habits. Paired programming can help put pressure on people who spend too many hours surfing the web and not enough hours working. Paired programming can help to discover who is productive and who should be fired.

The most bug-riddled code is in the code which is old, has had a lot of modifications over time, and has been worked on by a lot of people. I love git-blame, it tells an amazing story about the code you're looking at.

Looking over history is interesting, yes.

Looking over code like that tells many different stories. I have been assigned to research those stories before.

In the past one of my occasional assignments has been to monitor code submissions and statistics and the time spent correcting bugs. One thing I learned is that some developers write an incredible amount of code. Often the people who write the most bugs also have far and away the most code, sometimes 3x to 5x more than other team members. While the total count is high, the bugs-per-feature count is low because they do so much. The bugs they write are usually trivially corrected. Then there is the opposite end of the spectrum. Often those who vocally complain about problems submit fewer than average amounts of work, their submissions are less frequent, and their bugs are more severe.


Someone may introduce more bugs than another by count, that is true enough. Be prepared to look at a broader picture. Sometimes in development it is better to have someone introduce a few bugs while adding a large number of features. Becoming feature complete with bugs is often far better than spending months discovering the optimal search heuristic.

Again, if there is an issue in your work place you should spend some time to make sure the problem isn't you.

Those who spend their time building solutions and solving problems tend to accomplish great things. Those who spend their time in blame and accusations and fault-finding tend to find themselves unemployed. Are you a part of building the solutions?
Check out my personal indie blog at bryanwagstaff.com.

#8 Memir   Members   -  Reputation: 129

Like
-1Likes
Like

Posted 02 April 2014 - 08:59 AM

Thanks for your replies, especially frob.

Yes I'm a very critical person, and take much time to try to criticise my own work. Asking questions such as how much work I'm doing vs how much bugs I introduce etc.

In a nutshell, the problem can be see one of two ways.

1. The management are not taking the (right aspects of the) project as seriously as they should be. Instead of hiring weak developers, and developers who have no passion beyond doing the minimal amount of work to maintain their job. They should be hiring the best in the industry. They can afford it after all. So it's a tremendous waste of resources.

2. The problem is with me. My standards and expectations of the project are in realistically high. I want a product that will dominate the industry when it's released. I shouldn't care about my work, beyond the paycheck.

I do sometimes move to position 2. But then it makes me feel soulless, that a big part of my life (work) is just a waste, an exchange of time for money. The projects which I'm most proud of are the ones where they have affected other people I.e. The masses and I can tell my friends 'I worked on that'. Makes me feel like my job had a real purpose.

For what it's worth. It's hard to accurately measure productivity in this industry. But for line count I write at least 2 times as much code as the next person. While I seldom break the build. When there are bugs found, it's very rarely my area of the code, and when it is. It's usually very trivial to fix, mostly turns out to be a requirement that hasn't yet been complete rather than a real bug.

It's real simple. I'm just a lot more experienced and faster than the others in the team. It happens.

They pay my bills & pay a lot more than my previous company (despite work being far easier). So I go with it. But I employ various strategies to minimise the pairing. Even if it means agreeing with another co worker to say that we paired on a task. Essentially lying.

If I did pair properly. I would probably quit as it's not good for my mental health. Time + pain = money is the equation.
Flash Pool - Pool/Billiards game for Facebook (developed by Memir).

#9 Memir   Members   -  Reputation: 129

Like
0Likes
Like

Posted 02 April 2014 - 09:20 AM

Oh and I've worked for a dozen different companies. This is the first to advocate pairing and it's mostly confined to our team.
Flash Pool - Pool/Billiards game for Facebook (developed by Memir).

#10 Lantre   Members   -  Reputation: 184

Like
1Likes
Like

Posted 06 April 2014 - 02:06 PM

Pair-programming is effective primarily when used with foresight in a per-case situation.

There are times when I work best alone, as should be true for all of us over half the time to varying degrees.

But in some cases I need to implement an algorithm into an existing code base and I am not very familiar with the code.  Pairing up with someone who knows the code base is quite efficient.

 

I explain and code the algorithm or feature while asking, “Now I need the part of the code that handles this,” and he or she quickly directs me there, explaining any caveats I need to know before proceeding.

 

 

As with most things, it’s usually only “purely bad” because it is not being used properly.  If utilized correctly it does have a good side.

 

 

L. Spiro

 

This particular scenario could probably be extended to cover any instance where you have a subject matter expert pairing with an implementation expert. I.E. when you have someone with significant knowledge of the problem space/domain (e.g. AI, physics, networking, etc...) and someone who is familiar with the solution space (e.g. C++, Unity, some framework or another, etc...).



#11 ChaosEngine   Crossbones+   -  Reputation: 2357

Like
2Likes
Like

Posted 06 April 2014 - 03:38 PM


But I employ various strategies to minimise the pairing. Even if it means agreeing with another co worker to say that we paired on a task. Essentially lying.

 

Don't do that. 

 

If you genuinely feel that pair programming is making you less productive, take it up with your manager. Suggest some metrics by which to measure your productivity and ask for a 1 month trial period of working alone vs. working in a pair. If they agree; great, here's your chance to prove your assertion. 

 

But if they come back and say "no, we feel that pair programming is part of our team culture", then you have two choices: adapt or leave. 

 

If you really disagree with any given practice in work environment, you should absolutely say so. In fact you have a moral responsibility to your employer to do so. But if after you've discussed it with the team and people have made their decision, then you should abide by that. There's nothing worse than someone on the team poisoning the environment. If you really feel that strongly about it, then the only moral course of action is to find another job.

 

Personally, I think pair programming can be useful in certain circumstances (training a novice, working on a task that's open-ended, etc.) but yeah, for the majority of the time, it's a massive resource drag. 


if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS