I have a special interest in designing object-oriented architectures, distributed computing, projects that involve integration technologies, Continuous Integration as well as agile methodologies
Hi, nice article. Let me try some another approach. I saw a lot of benefits really similar when we are pairing in all development about the feature. So, and if the team pairing instead of to make the review process? This way the spirit/mindset of collective code code could be more shared by the team, and the feedback can be almost immediately without need to wait until of conclusion of the feature.
What do you think?
I have a special interest in designing object-oriented architectures, distributed computing, projects that involve integration technologies, Continuous Integration as well as agile methodologies
And, answer your question in my current project we are pairing and doing a code review. As we have a distributed/remote team with different timezones this way have been extremely helpful for us. As the code is a legacy usually we can have someone that already touched in that code looking on this and bringing up some new context about some decisions made.
In a mature team my feeling is that the code review is almost optional since we are doing the cards pairing and with pairing rotations.
Regarding the mature team, I personally think it is still worth reviewing (or pairing). It will still help to find bugs and problems and will spread the knowledge about new features.
If you feel pairing helps you to achieve all that, perfect!:)
Do you pair 100% of time? Can you tell me a bit about the process when you pair?
Hi Samuel,
Thank you for your reply! I never managed to pair-program for a prolonged period of time and consistently. But I guess it should be almost the same. Two pairs of eyes looking at the same code should definitely help.
On the other hand, pair programming 100% of time strikes me as, maybe, a bit too much? With code review you spend less time on reviewing then on writing.
Finally, I usually work in iterations, making my code work first and good in the end. I can imagine my coding partner to be frustrated by this in the beginning, and giving me feedback too early.
But again, I only pair-programmed on several occasions, so I don't have enough experience with it.
I have a special interest in designing object-oriented architectures, distributed computing, projects that involve integration technologies, Continuous Integration as well as agile methodologies
About my experience pairing in features and bug end-to-end:
There is no sense about who is the coding since both are working together in the same code, switching idea all the time and the keyboard;
The idea about collective code increase a lot; There is no "my code" and yes "the code that we did";
We broke the pair times and times in one card when we notice that the next steps will be operational like repetitive tasks; (So, not 100% all the time)
Two eyes with different backgrounds help a lot to create a better solution, and believe, faster;
Islands of knowledge it really uncommon;
Yeah, I really recommend and I could say that the benefits could be noticed fast; Obviously that all the team should accept the idea to try it.
Thank yoi for sharing! I like the "our code" feeling.
I also wonder if you really measured velocity and saw it's higher? I imagined, based on other people opinions mostly, that velocity should drop. If you managed to speed up, it deserves a publication!
I have a special interest in designing object-oriented architectures, distributed computing, projects that involve integration technologies, Continuous Integration as well as agile methodologies
Yeah, I'll try write. :)
The count base where we could notice the velocity increase was points delivered of features vs bugs card in some short cycles.
It was not so evident in the first ~2 months about after that we could compare the numbers. It's a mindset change of the team but I truly believe worth it.
I have a recent really good example where I had pair with a team from another squad in a feature and the solution came up with an idea that I put on the desk and his as well. When we shared the solution with the team in a stand-up meeting that team was really surprised with the "out of box" solution.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, nice article. Let me try some another approach. I saw a lot of benefits really similar when we are pairing in all development about the feature. So, and if the team pairing instead of to make the review process? This way the spirit/mindset of collective code code could be more shared by the team, and the feedback can be almost immediately without need to wait until of conclusion of the feature.
What do you think?
And, answer your question in my current project we are pairing and doing a code review. As we have a distributed/remote team with different timezones this way have been extremely helpful for us. As the code is a legacy usually we can have someone that already touched in that code looking on this and bringing up some new context about some decisions made.
In a mature team my feeling is that the code review is almost optional since we are doing the cards pairing and with pairing rotations.
Regarding the mature team, I personally think it is still worth reviewing (or pairing). It will still help to find bugs and problems and will spread the knowledge about new features.
If you feel pairing helps you to achieve all that, perfect!:)
Do you pair 100% of time? Can you tell me a bit about the process when you pair?
Hi Samuel,
Thank you for your reply! I never managed to pair-program for a prolonged period of time and consistently. But I guess it should be almost the same. Two pairs of eyes looking at the same code should definitely help.
On the other hand, pair programming 100% of time strikes me as, maybe, a bit too much? With code review you spend less time on reviewing then on writing.
Finally, I usually work in iterations, making my code work first and good in the end. I can imagine my coding partner to be frustrated by this in the beginning, and giving me feedback too early.
But again, I only pair-programmed on several occasions, so I don't have enough experience with it.
And what is your experience?
Sorry by the late message.
About my experience pairing in features and bug end-to-end:
Yeah, I really recommend and I could say that the benefits could be noticed fast; Obviously that all the team should accept the idea to try it.
If I could point to big themes should be:
=)
Thank yoi for sharing! I like the "our code" feeling.
I also wonder if you really measured velocity and saw it's higher? I imagined, based on other people opinions mostly, that velocity should drop. If you managed to speed up, it deserves a publication!
Yeah, I'll try write. :)
The count base where we could notice the velocity increase was points delivered of features vs bugs card in some short cycles.
It was not so evident in the first ~2 months about after that we could compare the numbers. It's a mindset change of the team but I truly believe worth it.
I have a recent really good example where I had pair with a team from another squad in a feature and the solution came up with an idea that I put on the desk and his as well. When we shared the solution with the team in a stand-up meeting that team was really surprised with the "out of box" solution.