They say, “Two heads are better than one”, and this is true, especially when working in Stockport’s software development team. Over the last couple of years, we’ve adopted ‘pairing’ as a strategy/method in software development and it’s working for us.
In a nutshell pairing is an agile software development technique in which two developers work together on a task at a single location, sharing a desk, PC, monitors and often keyboard/mouse. You do get your own chair and coffee mug.
If this technique is new to you, it’s sometimes a difficult transition from working on your own and it’s never 100% perfect, but the benefits definitely outweigh the drawbacks.
What are the benefits?
- Constant code reviews. You can’t write anything without getting comment from your pairing partner who tells you “You’ve misspelled String” or “You do that with an Await”. Or better yet, “That’s great but I did something last week which means we can … (grabs the keyboard and mouse and reduces 10 lines into 4) … do this.”
- Socially we work so much better as a team since we must work together. We all have to get on with each other or at least learn to tolerate each other’s little habits. If they tab and you space, it’s not the end of the world… you just tell them they are wrong and move on with the day! Having a discussion on why one thing is better than another is a great learning tool.
- The master can teach the student and vice versa. Due to how we’re made up as a team, we have varying levels of knowledge. That’s not to say everyone who is senior knows more than a junior. Sometimes the knowledge is in the junior member of staff as they worked on that area more recently. Sometimes the junior asks the obvious questions that we’ve not thought of asking and this can lead to improvements. The fact that we work on so many varied code bases means we all have pockets of expertise we can teach to others. For the most part, the act of pairing off a newer member of staff with an old hand means we get one-to-one training. Sometimes teaching or explaining something can lead to new insights for both parties.
- There shouldn’t be silos of expertise. We try and avoid the same person(s) working on a single area/skill. We rotate people in, to learn and spread the knowledge.
Versions of Pairing
- Driver navigator. This is where one person is on the keyboard while the other person in the pair directs what they do. Then after a fixed period of time the roles switch and the one giving instructions has time to put their words into practice.
- Ping pong (or wiff waff). This is best used when writing tests but can be adopted elsewhere. One person will write a test or a method name and the other person has to write the actual code. The roles are flipped on the next bit of work.
- Tour guide. This is used when there is an expert in a field and a novice is looking at the code for the first time. It’s the job of the tour guide to give a good explanation of what is going on, how it all works (or why it doesn’t work if we’re fixing a bug). Hopefully, in-time, the former novice can be the tour guide for the next novice developer.
- Mobbing. This is like pair programming but taken to the extreme. This would usually happen on a new project, or a technical task which may be a new experience for a large portion of the team, or one that has benefits from being done as a group. We would book a day and as a group work through the problem.
The drawbacks
- An uneven number of developers. Actually, this isn’t a problem but an opportunity for someone to work on their own on something that doesn’t need to be checked constantly, or something they are experimenting on. They play back their work to other developers later. Additionally they are often found supporting pairs that may need guidance and advice.
- “Not you again!” We try and pair evenly, to avoid the same two people always working together. We use pair stairs where we record a tally of who works with who, so over time everyone will have worked with each other evenly.
- “You’re not in tomorrow?” We always have an issue where a pair is broken up by holidays, sickness, or more frequently, meetings. But that’s a great opportunity to bring someone else in to look over what you’ve done, further spreading the knowledge.
- “Your desk is a mess!” Having someone sitting at your workstation makes you aware that you need to keep a tidy desk.
- “I don’t have the first clue about this and neither do you… what should we do?” Because we all work well together we’re always happy and on hand to help out other pairs.
- Pair rotations. If a pair has been unable to make progress on a task after a period of time, a fresh pair of eyes can be what is required to move the issue forward. Time boxing tasks is a strategy to reduce risks, by giving a pair a set time to investigate the issue. But pair rotations can cause a problem if done too often, as developers do not see the end of features, whilst switching contexts often means more time taken to get up to speed on the next issue.
- Pairing of two junior developers. Whilst this usually works well, this can be an issue if they get lost in the problem and spend hours trying to debug the same code over and over, only for another developer to find the issue in a few minutes. As we have a larger ratio of junior developers to senior, where we pair junior developers together we support them with a senior developer on hand. This way they can work through the problem, allowing them to make mistakes and learn from them, but still with support close by from more experienced developers.
All in all, working as a pair in Stockport’s software development team has a lot to recommend it. If you’d like to join us we do have vacancies for software developers so please take a look at the job spec or get in touch if you have any questions or would like to find out about other opportunities.
For regular updates from the #DigitalStockport blog sign up for email alerts.