Our company is a mobile application developer and throughout our work process we are continuously experimenting with new approaches and methodologies that would speed up the development process while maintaining quality results.
In this article, I will describe my personal experience of pair programming, how the technique is applied on actual projects at our company, as well as the findings and results we were able to reach with this technique at Stanfy.
First, however, I obviously have to provide a disclaimer. Everything I talk about below is based solely on my personal impressions and findings about pair programming. Even the programmer working in a pair with you may have impressions that are completely different from yours.
The name of the methodology speaks for itself. To give an overview, it is necessary to provide a basic definition of this approach and the terms that I will use below:
Pair programming is a software development technique in which two programmers work as a pair together on one workstation. One of them writes code while the other monitors the process.
When defining the roles in the article, I will use the Agile Alliance terminology wherein the one who writes code is the driver and the other one is the observer or navigator.
It is important to adjust the time period for when the two persons can swap roles–as a rule, between 20 minutes and 1 hour. At Stanfy, we have been able to empirically establish that 30 minutes is the optimal duration so that one person does not stay away from the keyboard for a long time and does not disengage.
At the same time, the driver has enough time to complete a minimum new functional code. As the concept of working in a pair is not new in itself, over time patterns of how exactly people can work in pairs have evolved. I will provide the most common ones.
It can be said that it is the most classical approach to pair programming. You just pull up a chair and sit next to your colleague.
The advantage of this variant is its speed (no need to set up anything unnecessary). However, a great disadvantage is that it creates an unfamiliar situation for one member of the pair. Indeed when you sit in a pair with somebody, the whole environment — from the keyboard and layout to hotkeys — becomes unfamiliar.
It can be said that the classic is the next level after the Lazy. There’s still just one computer, but the main difference is that there are 2 monitors, 2 keyboards and 2 mice. It should be noted that the computer should not belong to either pair; the workstation should be a separate, “neutral” machine.
This set-up of the work environment offers many advantages: quick swapping of roles, no distractions by personal life matters, universal hotkeys and IDEs for all the team members. The drawback of this pattern is that it is quite costly in terms of allocating a dedicated system that will be solely used as a station for pair programming.
The above variants are more or less classical options. Those that follow are a few variations.
The Noob does not involve role swapping per say. There are still two persons sitting at the computer, but only one of them writes code. Many sources say that this variant is the best for training, as the navigator can ask questions in the process of writing code and observe what is happening.
Based on our experience, this approach can also be used by a pair of expert programmers. This pattern helps overcome 2 important obstacles in the way of effective performance: unfamiliar environment and wasting time on swapping roles.
Obviously, the main drawback of this pattern is that the navigator is likely to lose interest or lose the driver’s logic in writing code. In such cases, the navigator should stop the driver and enquire until all i’s are dotted.
This approach is a Lazy variation where the navigator has his/her laptop at hand. This extra computer is used to search for information or to clarify certain details of the process. It should be noted that the navigator still has to look at the driver’s monitor for most of the time and watch what is happening there.
A potential advantage is that it boosts productivity, as the driver doesn’t have to divert his attention to google something. He/she can concentrate solely on writing code and get new information from the navigator.
As with the Noob, the main drawback of this approach is the high possibility for the navigator to get distracted by a Skype message, an email, etc. Compared with the previous approach, the possibility is several times higher here, as there is a personal computer in front of the navigator that could be a constant source of distraction.
Of course, on paper the idea behind the methodology seems ideal. In an ideal world, productivity increases, tasks are written faster, and there are fewer bugs. And it would have been true if machines were writing code. However, as pairs are human, the approach is not all that smooth and ideal. Therefore, in the present article, I will try to answer the following questions:
- Is there an ideal situation to work in pair with someone?
- At the end of the day, are there any benefits from working in pair? And what are the pitfalls?
- How do we, at Stanfy, apply pair programming?
The right time for pair programming
Is there a right time to work in pair with someone? No, there is no such time; there are no hard and fast rules about the best time for pair programming. However, there are situations where the value of pair work increases significantly. These situations are:
- when a new person joins a project
- problems with a new functional code, with fixing a bug
- demonstrating the efficiency of a new technology/library/methodology (RxJava, TDD, etc.)
- job interview
A new person joins the project
As we know from Brooks’ classic work “The Mythical Man-Month”, when working on a large project, a newcomer needs between 3 and 6 months to thoroughly learn all the components and only then his/her productivity would be at required level.
When a new person joins the project, simple knowledge of language and technology is not enough for faster integration. Working in pair with a newcomer for at least one day will significantly improve his/her understanding of what is happening in your project. What each component is responsible for? How does the process of publishing and implementing a new functional code work? How do different parts of the system interact with each other? A newcomer would find it quite hard to answer these and many other questions.
Pair programming allows a significant reduction in learning time, as someone who has been working on the project for a long time introduces the newcomer to it. When working on real tasks, questions arise that would have otherwise not popped up if the project was simply introduced in 5 minutes.
Implementation of the new functional code/fixing bugs
Sometimes when developing a new functional code you get lost in your own code. When the number of new lines increases, the task seems completed and yet some faults constantly come up (new bugs relevant to the new code). If you remember the value graph of the bug based on the time the bug was detected, it is quite reasonable to ask someone to evaluate your solution before the PR stage.
You might get some ‘WTF?!’ or some other comments and advice on how you should have done it. However, it is sometimes difficult to understand someone else’s idea, especially if you already have your ‘almost working’ code. On the other hand, it is also difficult sometimes to give advice or offer an alternative solution without understanding the problem as a whole and being away from the actual code. In such situations, pair programming allows for one person to demonstrate his/her idea and the other person to better understand the logic of the new implementation.
From our experience, even one day of pair work is enough to give a nudge to complete the task. You can ask one of your colleagues the night before or at a stand-up to sit with you in pair for half a day or a day so as to give fresh impetus to solving the problem. No one refuses and everybody finds the time to help a colleague, as we all understand that at the end of the day we are a team working together for the development of a shared product.
Demonstration of a new technology/library
Today, new libraries/frameworks/approaches for programming are constantly being developed, and sometimes it is difficult to keep abreast and follow all these new developments. Therefore, a good time to work with another programmer to write code is when a member of the team has learned a new technology/library. Thus, by working in pair, the acquired skills can be passed on much faster. This is very efficient when you need to tell a person about the internal libraries used, how to use them correctly and why they’re effective.
As a hiring step
In Stanfy, we actively use a day of pair programming as one of the steps for hiring new programmers. A candidate works in turn with all the team members for a day. This way we are able, on the one hand, to evaluate the applicant’s technical skills, and on the other, the applicant gets a chance to get to know what he/she will have to work with, the technologies used and the level of his/her potential colleagues.
Advantages of pair work
Now, let’s talk about the advantages. There are advantages to pair work despite the fact that they’re not that evident at first sight. So, for me the main advantages of writing code in pair include the following:
- better code quality at completion of the task
- better understanding of the project and the changes to it
- better understanding of the code of the people who work with you on the project
One of the main advantages, however obvious it may sound, is the quality of the code that is obtained at completion of the task. For, working in pair, one writes code while the other has nothing to do but to be a non-stop reviewer.
If a code doesn’t appear clear for the navigator, the more difficult its readability will be for someone who would have to deal with it in the future. This is the first cue to make comments/perform refactoring. When writing code, sometimes you can forget for months to apply the code style, left TODO comments, debug logs, etc. Experience shows that at least one of the pair will remember about all these things.
Deeper project knowledge
Pair programming not only allows the fixing of potential bugs but also increases the team’s overall familiarity with the latest changes to the project. Let’s say that two programmers have completed their respective tasks. Each of the tasks is “uncharted territory” for the other; the most each programmer can do is to look at the final code review. And even then 2 problems remain: the team might not use code PR and review, and even if they do, the final code is not always clear and readable.
If the 2 tasks are written by the same two programmers, working in pair, both would understand the new code and functional code. Thus, a significantly deeper knowledge of the different components of the system that the team works with can be achieved.
Helps understand a team member
When someone else is at the keyboard and you are just observing, you can better understand the code that the driver is writing if you watch how it is being written. This helps better understand what guides the person when making this or that decision. Pair work teaches the pair that his/her idea is not necessarily right and is subject to change, and the idea that he/she will have to apply will not be necessarily called the way he/she calls it.
Disadvantages of pair work
Now, let’s go on to talk about the disadvantages. The word “disadvantages” is not quite appropriate here, rather, it is better to refer to “obstacles” in the way of productive performance. To understand what the main obstacle is, it is worth noting that such work requires the time of 2 programmers and that this time is most efficiently spent writing code. Accordingly, anything that hinders writing code or discussing the right solution (the solution itself, not minor details of implementation) is considered an obstacle. In particular, these include:
- personal life (working hours, lunch break, chats with cats in Skype, etc.)
- work environment (IDE, shortcuts, familiarity with keyboard layout, etc.)
- discussions of the small details of implementation (name of the variable, some other minor refactoring).
Business emails, messages of funny cats in Skype, different working hours, private life: these are not that terrible individually, but together (as is usually the case) they waste so much time that it is clear right away that pair work is utterly inefficient and a waste of time. This particularly concerns the person who acts as the navigator. When you are not writing code yourself, you can be easily distracted by a new message on your phone. The driver takes note of such behaviour and allows himself the same after swapping roles. Such things reduce the productivity of the team as a whole.
As a result, in order to achieve productivity, first and foremost, the factors mentioned above should be minimised. If you know that you will be working in pair the next day, agree on the working hours. This would include arrival time, lunch break, etc. You would also need to agree on occasional breaks to check your Facebook accounts. A break every 2-3 hours will give each of you time for personal matters.
Getting used to the new work environment (when the accustomed hotkeys do not work, or the keyboard layout is unfamiliar) can take too much time and bring on frustration, and thoughts like “Why do I need this pair work?” Therefore, you need to get rid of the cause for discomfort related to the unfamiliar workplace. The ideal option for the work environment is a 3rd “neutral” computer that, on the one hand, will be minimally personalised, and on the other, will allow the two programmers to get used to it with continued use. If a team applies pair work, a good personal practice would be to use standard settings for hotkeys and keep their personalised customisation to a minimum. This way, if you have to use another machine, you will not get irritated that the shortcuts are not working the way you want them to work.
Development speed decreases frequently
Development speed decreases. This is a widely known problem and brought up every time someone hears about pair programming. However, the main challenge of a slower pace is not that one task takes the time of 2 programmers.
The discussion of minor details may lead to disputes and this is a very undesirable, as it not only slows down the work on a task but also harms people’s relationships. In fact, this might be the biggest danger among all the disadvantages listed above, as it does not merely slow down the work but also after several such minor conflicts, the relationships between colleagues would break down and a kind of “anti-teambuilding” atmosphere would settle.
There is no 3rd party and no one can arbitrate in your dispute, so a good rule of thumb is to always remember that the ultimate goal is a completed feature with a well-tested code. Keeping this in mind, many a discussion can be avoided without even going into it. Of course, if you definitely know that a certain code will lead to memory leak, you should not keep silent. But remember that “because I think so” in not really a valid argument.
At Stanfy, pair work sessions may be limited to a day, a week or a specific feature when people sit together until they completed a certain functional code. There were situations when one person only wrote the code during a day, and yet the navigator was constantly engaged in discussing of implementation and giving useful advice on code change (Noob pattern). And, given the obstacles relating to the different work environments of various approaches, this appears to be not too bad of an idea for efficient work.
Unfortunately, there is no silver bullet, neither is there an ideal situation when pair work is a requirement. Therefore, this matter requires flexibility. There are many articles on pair programing available on the Internet; largely they list similar advantages and disadvantages of pair programming. The main thing to remember is that pair programming, like Agile methodology, is most beneficial when it is adapted as far as possible to your work environment. One should always remember that this approach is just a tool that helps create a quality software product. You don’t have to use it all the time, but it would be reasonable to keep it in mind.
If you have any questions about app development, get in touch with us. We would love to hear from you!
September 16, 2015