4 ms·

I agree with your points, but the pair programming also has downsides, main one being that it doubles the total cost per task, and also it's usually limited to

I agree with your points, but the pair programming also has downsides, main one being that it doubles the total cost per task, and also it's usually limited to 2 pairs of eyes (again because of the cost), while code reviews can (and should) be done by as many members of the team as possible.

tcbasche 5y ago
That “doubling of cost” thing is utter rubbish. If you produce higher quality code with two people deeply aware of the design and maintenance of a system doesn’t that reduce overall cost? I swear this “doubling cost” is one of those myths perpetuated by Taylorist managers. I’ve never seen any evidence to suggest pairing is less efficient overall.
- ivanhoe 5y ago
  > I’ve never seen any evidence to suggest pairing is less efficient overall. It's not less efficient, but is it really 2x as efficient as having a single senior dev per task, with proper code reviews and tests in place? And it does cost double upfront, you can't avoid that and costs are the limiting factor for many (especially smaller) teams... some of this cost will pay back in terms of bugs being less likely and easier future maintenance and all that, but can you really claim that it will absolutely ALWAYS return the initial investment? To paraphrase on your own words: "I’ve never seen any evidence to suggest it's guaranteed to be that much more efficient". IME (and I did a lot of pair programming in my career) it depends a lot on the people being paired, how complementary their way of thinking is, and also on the particular task being worked on. It will never produce a worse code than solo programming, that's for sure, so it's great if you can afford it, but if you can't there are other ways around it to come close (code reviews being one), and that was the whole point of my comment.
  - lmilcin 5y ago
    You argue the pairing is more expensive and then give arguments to the contrary. To be sure, pairing, in order to be effective, has to be properly planned and executed. It is unlikely to work if you just leave it to your employees to figure out (unless you have some really good folk that can figure it out).
lmilcin 5y ago
> main one being that it doubles the total cost per task Oh, that is false. I guess it comes from a simplistic understanding of how people work (no, they are not robots). You may have two people engaged in the same task, but: * People are more focused and work faster -- it is much easier to stop yourself from procrastinating when you have other person on the call. * You get people exchanging tacit knowledge. With people changing pairs knowledge will tend to spread over entire team eventually very efficiently. * You get flexibility of having any of the two people being able to continue the task (if one quits, is sick, has to take day off or step out for a meeting) -- the work is much more likely to progress uninterrupted. * You get much less chance for the project to get stuck. When one person doesn't know how to do something the other person might know. * You will tend to get better quality results (for example any bug needs to pass through two pairs of eyes, etc.) -- and that means less time wasted on other parts of the pipeline, less technical debt, etc. * When you get a new dev on the team, the first assignments are much less likely to get screwed up because you have other seasoned dev in the pair. * You get a natural mechanism to get a new dev onboarded and have knowledge transfer -- they get up to speed many, many times faster than if they are just dropped alone on a task. * Good code review isn't free either, it would have to take a significant portion of the effort to write the code anyway. * You get people socialising while doing useful work. Which is extra difficult while working remotely. Having tightly knit team is very valuable. * People are overall more happy and engaged when the work goes faster. Have you noticed you feel better when you stand in one long queue that progresses fast than if you split it into multiple queues that progress slowly, even if overall wait time is the same? * Having work done faster (by two people working on it at the same time) makes for faster cycle time and in consequence lower complexity (less things being worked on at the same time). Lowering complexity is very valuable. * While we are at complexity -- normally doubling people in the project does not cause it to progress twice as fast or cause the throughput to be twice more. Being able to treat two developers as one, uber-developer doing work more efficiently is very valuable because it allows counteracting at least part of that diminishing returns trend (ie. you have have larger team with efficiency of a smaller team). * As a tech lead this is fantastic way for me to get to know people, their strengths and weaknesses. I can then help them with weaknesses and maybe learn something from their strengths. Getting to know the complete picture of the team is extremely valuable. And many other reasons. When you take that into account you will find that, if done correctly, pair programming will be more efficient. Especially long term, because some of the effects take time to kick in. ** Now, working in pairs isn't free: * Working in pairs requires people to have high standards when it comes to their behaviour towards their peers. Working in pairs requires absolute adherence to the "no asshole" rule. * As a manager, you need to react very quickly to people having trouble working together because in pair programming this is going to immediately destroy productivity for two people. * Costs of disruption is magnified when working in pairs. For example, if you have to wait for approval for something -- now you have two discontent people waiting for the approval. If one person has to join a meeting -- the other person will not be as efficient and they will have additional cost of syncing afterwards. * You probably want to hire people that are specifically mentally designed to be able to work in pairs. Some people just prefer to isolate themselves and work alone -- these will have trouble functioning in a team that uses pair programming. It doesn't mean these people are worse, they are just worse for that particular team.

tcbasche 5y ago

That “doubling of cost” thing is utter rubbish. If you produce higher quality code with two people deeply aware of the design and maintenance of a system doesn’t that reduce overall cost? I swear this “doubling cost” is one of those myths perpetuated by Taylorist managers. I’ve never seen any evidence to suggest pairing is less efficient overall.

ivanhoe 5y ago
> I’ve never seen any evidence to suggest pairing is less efficient overall. It's not less efficient, but is it really 2x as efficient as having a single senior dev per task, with proper code reviews and tests in place? And it does cost double upfront, you can't avoid that and costs are the limiting factor for many (especially smaller) teams... some of this cost will pay back in terms of bugs being less likely and easier future maintenance and all that, but can you really claim that it will absolutely ALWAYS return the initial investment? To paraphrase on your own words: "I’ve never seen any evidence to suggest it's guaranteed to be that much more efficient". IME (and I did a lot of pair programming in my career) it depends a lot on the people being paired, how complementary their way of thinking is, and also on the particular task being worked on. It will never produce a worse code than solo programming, that's for sure, so it's great if you can afford it, but if you can't there are other ways around it to come close (code reviews being one), and that was the whole point of my comment.
- lmilcin 5y ago
  You argue the pairing is more expensive and then give arguments to the contrary. To be sure, pairing, in order to be effective, has to be properly planned and executed. It is unlikely to work if you just leave it to your employees to figure out (unless you have some really good folk that can figure it out).

lmilcin 5y ago

> main one being that it doubles the total cost per task Oh, that is false. I guess it comes from a simplistic understanding of how people work (no, they are not robots). You may have two people engaged in the same task, but: * People are more focused and work faster -- it is much easier to stop yourself from procrastinating when you have other person on the call. * You get people exchanging tacit knowledge. With people changing pairs knowledge will tend to spread over entire team eventually very efficiently. * You get flexibility of having any of the two people being able to continue the task (if one quits, is sick, has to take day off or step out for a meeting) -- the work is much more likely to progress uninterrupted. * You get much less chance for the project to get stuck. When one person doesn't know how to do something the other person might know. * You will tend to get better quality results (for example any bug needs to pass through two pairs of eyes, etc.) -- and that means less time wasted on other parts of the pipeline, less technical debt, etc. * When you get a new dev on the team, the first assignments are much less likely to get screwed up because you have other seasoned dev in the pair. * You get a natural mechanism to get a new dev onboarded and have knowledge transfer -- they get up to speed many, many times faster than if they are just dropped alone on a task. * Good code review isn't free either, it would have to take a significant portion of the effort to write the code anyway. * You get people socialising while doing useful work. Which is extra difficult while working remotely. Having tightly knit team is very valuable. * People are overall more happy and engaged when the work goes faster. Have you noticed you feel better when you stand in one long queue that progresses fast than if you split it into multiple queues that progress slowly, even if overall wait time is the same? * Having work done faster (by two people working on it at the same time) makes for faster cycle time and in consequence lower complexity (less things being worked on at the same time). Lowering complexity is very valuable. * While we are at complexity -- normally doubling people in the project does not cause it to progress twice as fast or cause the throughput to be twice more. Being able to treat two developers as one, uber-developer doing work more efficiently is very valuable because it allows counteracting at least part of that diminishing returns trend (ie. you have have larger team with efficiency of a smaller team). * As a tech lead this is fantastic way for me to get to know people, their strengths and weaknesses. I can then help them with weaknesses and maybe learn something from their strengths. Getting to know the complete picture of the team is extremely valuable. And many other reasons. When you take that into account you will find that, if done correctly, pair programming will be more efficient. Especially long term, because some of the effects take time to kick in. ** Now, working in pairs isn't free: * Working in pairs requires people to have high standards when it comes to their behaviour towards their peers. Working in pairs requires absolute adherence to the "no asshole" rule. * As a manager, you need to react very quickly to people having trouble working together because in pair programming this is going to immediately destroy productivity for two people. * Costs of disruption is magnified when working in pairs. For example, if you have to wait for approval for something -- now you have two discontent people waiting for the approval. If one person has to join a meeting -- the other person will not be as efficient and they will have additional cost of syncing afterwards. * You probably want to hire people that are specifically mentally designed to be able to work in pairs. Some people just prefer to isolate themselves and work alone -- these will have trouble functioning in a team that uses pair programming. It doesn't mean these people are worse, they are just worse for that particular team.