Programming in pairs is one of the Agile methodology techniques. It could be really effective as it aims to improve quality of the code and as a result, decrease probability of bugs.
While the programming, the knowledge of two developers is instantly shared between them resulting big boost in the learning process.
We at Octivi also use this method in our developing process and would like to share with you some experiences we encountered.
As a mid-size developer team we never had problems with communication between programmers. Flat, non-corporation hierarchy makes every day really nice experience in developing and ensure no waste of time in taking decision process.
Some time ago we started a cloud technologies based project for one of our customers. Due to a freshness of the technologies used in it, we had to solve many tough tasks on our own, with even lack of documentation.
One of our programmers did really great job in making big research over the tools needed to use and as a result we could see promising results. As the project grown, there was a decision to join one more developer to it. That lead to introduce new features more rapidly and make our client as pleased as possible.
It was also a good moment to use programming in pairs method as the previous developer had big insight over the project.
The purpose was to take a look on an already ready code, search for bugs, refactor some pieces and explain whole conception to the new programmer (me :-)). I have to say, this experience has shown me a lot, and I’m really glad that we did this in that way.
Part I – Project introduction
First of all, when the author of a code can show you his solution and explain how it works everything becomes really simple.
You can share thinking process and receive answers without long self research. It’s quite normal, that you can’t talk about every small solution, but a lot of work he did was understandable for me after less than a hour. We were searching for solutions adopted, he showed me some of his concepts.
Part II – Bug detection
So, we searched for bugs, we detected some not-really-save parts. This is something what makes this method really great, new point of view, new perspective. Additionally we were able to made it as a challenge called You just can’t hack my system 🙂
The searching of bugs or better ways to do something in the project managed by someone else is a really tough job. I’m not only talking about the pure programming aspect but also the social one. Pointing out errors and asking too many questions can lead to some stress. Such thing can also have influence on the future relations with the other developer.
Part III – Refactoring phase
The refactoring was the part when we could verify new concepts, think together about new solutions and share our knowledge.
One of your main developer tools are Google and Stackoverflow. You still sometimes have to search for the sample usages of some methods, especially when you are making the code which handles connections to some 3-rd party Webservice. Keeping this in mind, I suggest to use two laptops, not only one — for the writing programmer 😉
Another problem was with the aspect, which we firstly found as an advantage. Sometimes my colleague just hardly convinced me to think in his way. I had to urge with him about the other possible solution which in my opinion would fit better.
At the end of a day…
After all I felt really comfortable with the new code. In my opinion, after that, I could easily find some necessary parts and add new feature to the current structure.
Before the day ends…
- I had the full overview on the project
- We solved some bugs
- We refactored many lines
…and I felt that I’ll be able to develop it further easily 🙂
Photo by Sebastiaan ter Burg