4 ms·

Except I don't believe in code reviews. Over the years I have experimented with pair programming and I think it is way better solution. The one catch with pair

Except I don't believe in code reviews. Over the years I have experimented with pair programming and I think it is way better solution. The one catch with pair programming is that some people just prefer to work alone and it is really draining to be talking constantly for couple of hours. I have modified the system to do on/off pair programming (ie. split up a little bit of work, rejoin later in the day, share what we have done, and work a little bit together). The basic, unsolvable issue with code reviews is that the review is done after the code has already been written. As you know, the cost of fixing a problem is larger the later in the process you catch it. Pair programming aims to accomplish the correction while the code is being written. Another huge problem is that, because the reviewer is not taking part in the development, he/she does not have the same level of understanding of what was supposed to be done. Also, code reviewers are typically disincentivized from doing review well: * They have other tasks to accomplish, review takes their time away from those tasks but the deadlines are not pushed automatically, * The review tends to land at a random point in time disrupting their flow -- they have something else in mind already and they want to switch to their work as quickly as possible -- meaning they will not want to get into great detail with understanding the problem. This causes reviews to usually be very shallow and focused on trivia. Usually, I see reviewers read the code file by file line by line, hundred times faster than it was written. It is absolutely impossible to verify a large change like that and this guarantees that they will not actually verify it thoroughly. Yeah, you may find superficial flaws, but that's about it. Other problems: * The developer feels resentment because he/she thought it was all done. * A lot of effort was spent on a wrong solution which is lost productivity. * From project management PoV it is a problem because we can't tell how much time/effort it will take until last second. * Reviewers feel pressure to find something so they will just report trivia if they can't find real issues. * Reviewers tend to not want to report huge issues that would require complete rewrite because they are developers themselves and wouldn't want the same happen to them, and also because they are typically members of the same team. * and so on.

ivanhoe 5y ago
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.

ivanhoe 5y ago

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.