Teaming Up on Quality Before Test
How Pair Programming, Mob Programming, and Code Review can help your team deliver a better product.
There are many times in life where “the more the merrier” makes sense, but is the same true in software development?
When we talk about writing code and creating features, it’s often thought of as a one-man job -- we picture a single developer working at his or her machine completing tasks alone. However, teams are experimenting with more ways to work collaboratively.
As teams shift left, adopt agile methodologies, and make the effort to focus on quality throughout the entire lifecycle, developers are now being held to a higher standard when it comes to the quality of their code.
Collaborative processes like mob programming, pair programming, and code review are taking center stage to address this challenge. But what are they, and are they right for you? Let’s investigate how these measures are helping teams achieve quality before testing.
Pair Programming & Mob Programming
Pair programming and mob programming are both fairly straightforward concepts, but they come with benefits that may not be as obvious.
Pair programming is a technique where two programmers work together on a certain task. One person is the “driver” who writes the code, while the other observes in order to provide feedback on the spot. Mob programming, on the other hand, consists of one driver and multiple observers.
Choosing between pair and mob programming largely depends on the complexity of the project you’re working on. Since mob programming usually involves the entire team working together, you’re getting various perspectives of different team members in a highly collaborative session.
On the other hand, having too many people working on one machine can also get overwhelming. Since problems can often be solved in more than one way, it is rare for team members to share the same vision. Pair programming ensures a more equal exchange of information between two people, who will usually switch roles between driver and observer.
The idea behind having multiple programmers on one job is that when just one person is focusing on actually typing and inputting code, it can be difficult to look at the bigger picture and consider the context laid out in user stories and requirements.
By having two sets of eyes looking at a single task, the other programmer can spot mistakes as they happen or notice when something may not be built according to those requirements. The result is that code is written to a higher quality than when it is written by a programmer working on their own.
Since both developers have to agree on the code, issues are found immediately and debugging can then be done right away, this means less time going back in to find and fix bugs after the entire feature is written.
If you ask the teams that are already doing pair programming, they’ll tell you the same. An online study showed that 96% of programmers preferred working in pairs to working alone, and 95% of them felt more confident in their code after being paired up.
While pair and mob programming are becoming more popular, they’re not for everyone. If you’re not a fan of someone looking over your shoulder while you work, you may have a preference for code review rather than mob or pair programming.
Code review is a similar concept to pair programming in that there are usually two people involved -- the programmer and the person reviewing the code. In the case of code review however, the reviewer looks at the code after the programmer is done to provide feedback and make sure there are no errors. Most often, they will use a code review tool to provide notes and document of the review.
Code review is a proven method used by 64 percent of teams to implement more quality gates into the software development lifecycle before test.
In fact, in the SmartBear 2018 State of Code Review, we found that respondents identified code review as the #1 way to improve quality. Additionally, satisfaction with one’s code review process was the most likely indicator of satisfaction with overall software quality, and satisfied teams were twice as likely to perform code reviews on a daily basis.
In college, we relied on our friends and classmates to review our essays. Sometimes there might have been a typo, sometimes we might have missed something that could’ve made it better, and sometimes we might have just gotten something totally wrong.
It makes sense that a similar peer review process could be helpful as we code new features and functionalities in software development.
In the same way that pair or mob programming can help reduce time debugging, code review also allows teams to address issues while they’re still top of mind. Not only will this be a huge time saver, it also reduces the financial implications of finding a bug later in the development lifecycle.
Pitfalls of Pairing Up
So, why aren’t all teams doing this 100 percent of the time?
First of all, with both of these techniques, you’re requiring the time commitment of multiple people on one job. Does this mean you’re theoretically splitting the productivity of two programmers in half?
Studies have show there is a significant gain in code quality of up to a 15 percent reduction of defects at the cost of up to 15 percent in overhead. Lower maintenance and rework later in the development life cycle also translate to a significant upside.
The moral of the story is that you want to make sure your team has the bandwidth to take on one of these techniques. You also need to assess how often practicing these methods helps your team accomplish their goals, and how long team members should be doing it at one time.
While code review is best performed on a daily basis, you may want to limit pair programming or mob programming to a monthly or weekly basis based on how large your team is.
Additionally, there are intelligent ways to try your hand at these methods. For example, it’s best to limit pair or mob programming to a few hours at a time, while you should review fewer than 400 lines of code a a time for no more than an hour.
It’s also important that all those involved are engaged in the process so that it’s not a waste of time -- you need a healthy team dynamic for these methods to be successful. If both parties aren’t committed to this type of collaboration, the value won’t be worth the time investment.
Alternatively, mob programming and pair programming can be subject to things like group think, competitive team environments, and can be more difficult to execute with distributed teams. While some have had success pair or mob programming remotely, it can be tough to organize a session that is practical for team members that don’t share the same workspace or time zone.
Code review with a dedicated tool has the added advantage that reviews can be conducted regardless of each team member’s skill level and remotely at each developer’s convenience, in a documented way.
Two Devs Are Better Than One
While we shouldn’t rely on pair programming, mob programming, or code review to be the silver bullet solution to quality, they’re certainly worth exploring.
These techniques are easy-to-try methods for improving communication, and there are many different ways to get started. Practicing one or more of these efforts on a regular cadence can effectively help spread knowledge and add a layer of quality assurance before putting the code through test.
As we discuss the importance of quality and continuous learning, pair and mob programming as well as code review are simple ways to make more room for collaboration.
Interested in learning more about Mob Programming? Join us in a free webinar for "Mob Programming Explained" on April 11th. Register now.