Peer programming, mob programming, solo programming…

A few days ago(weeks, months,.. when you read this) I founded this article and knew about “Mob programming”, a topic that was totally unknown to me. In the article, the author exposes problems with code reviews and peer programming and he tries to show us how it’s better to apply Mob programming. Here, I’m going to expose my opinion about how I like to work in a team and the good practices needed to make it works.

I don’t believe that there is only one unique way of work for teams, I rather prefer to adapt how the team works depending on: maturity of people in the team, the project status, the current kind of tasks in the project,… .

My preferred way for a development team is based on: solo programming, code reviews and peer programming, some of these are part of the development methodology called Extreme Programming. Let’s see benefits and problems with each of these concepts.

Benefits of solo programming

Photo by Wes Hicks on Unsplash

• Improvement of self learning: the need to make your own research and find the best solution.
• Ownership: be responsible for something.
• Self management: personal way to handle your own task.

Benefits of peer programming

Photo by Alvaro Reyes on Unsplash

• Second opinion: another point of view to solve a concrete problem.
• Knowledge sharing: when working to solve a problem, previous experience and knowledge can be shared.
• Immediate feedback: can make suggestions as soon as the other pair is creating a solution.

Benefits of code reviews

• Second opinion: another point of view about how to solve a problem.
• Code styling and technical suggestions: reviewers can give suggestions to improve readability, performance or fix possible errors.
• No pressure for immediate feedback and time to think and research: there is a chance to stop reviewing, read documentation and make research to give a better and more complete feedback.

Problems with solo programming

• One point of view: developing following own biases.
• Different technical levels: depending on the experience, the original task output can differ from each team member.

Problems with peer programming

• Energy consumption: talking all the time, communicating intentions and thoughts involves more energy from each of the team members.
• Need for immediate feedback and lack of time to think and research.
• Two people working on a single task, so more resources are needed for the team.

Problems of code reviews

• Time dedication: every reviewer needs to spend the right amount of time for a good code review.
• Good written communication skills needed: kind and correct comments.
• Context information for reviewer: it’s necessary to provide correct context and useful information to facilitate the task of the reviewer.

Good practices to avoid the problems

After reviewing some common benefits and problems for each technique, let’s see some good practices that help us:

• Good tasks splitting to ensure small tasks, easy and fast to develop and review. This helps to avoid problems for merging branches, reduce the amount of changed files and make a code review easier.
• Always have a backlog with tasks ready to work on. Linked with the previous one, having small tasks ready to start helps us to work on other tasks meanwhile one is in code review.
• Foster ownership and responsibility in each team member. Giving responsibility for finding solutions and asking for responsibility for results helps team members grow.
• Have a friendly environment that encourages asking for help. When defining a new complex task ,dealing with something unknown, or any other situation that is better solved by more than one person or that requires the knowledge of someone else, asking for help is the best option. Those are situations when “peer designing” helps and improves the quality of the solution.
• Continuing the previous point, when someone gets stuck on a task, asking for “peer programming” time to solve the problem is a better option than just keep “fighting” alone.
• Have a “template” or guide for creating the code reviews. It is important to attach all the necessary information for the reviewer: the context, the functional definition, the technical details or any other information.
• An agreement for how often people do code reviews. Define how a new code review request is communicated (perhaps you can have several for different needs).
• Each member should have its own way of work to ensure be able to meet the team agreements. In my case I work in small chunks of time to be sure I can keep going in my code, respond to communications, make code reviews, etc.. In my experience the smaller you split your tasks easier it is to follow this approach.
• Agreements and documentation about what type of things should be reviewed. Don’t allow a code review to take too long with too many messages. When it happens, open a meeting to fix the problem.
• Create documentation for knowledge sharing. This will help with the development of new tasks or in code reviews. Documentation should be a “living organism” owned by all people in the team/company.

About Mob programming and why I don’t like it.

• The company needs more teams to allow all people on each team work in a single task and move forward in different functionalities. Even when, with time, the speed may increase, the speed is going to be (or it should be) the speed of the slowest person in the team. If the speed is higher than the one a person can assume, then that person will be left behind the group.
• Is there a task so complex that it requires the whole team to work on it? Maybe it could be good for defining some architecture or similar, but hard to justify for creating a new endpoint for an existing API. For a new complex idea, a better approach for the team (and in general a company) could be: create a shared doc, add comments and improvements on it and finally schedule a short meeting to discuss some details.
• The energy consumption of being connected all the time, focused on talking and sharing with other people is too high. The stress that situation could produce to more introverted people could drain their energy.
• The need to synchronize schedules breaks the modern wave of freedom and own schedules that remote work gives. To work in Mob programming all the team needs to be “connected” all together all the time.
• People learn at different speeds. Depending on the subject, experience or personal background it will be more difficult or easier to learn something. Trying to synchronize people’s learning could generate frustration in your team.

To sum up, some points:

• There is no golden rule, select each technique for each case.
• Define procedures and ensure the team follows them.
• Read about what more advanced teams are doing and how they have solved the problems and take ideas for yours.
• Keep always improving your techniques.

I hope you enjoyed it and if you have something to add, please leave a comment.

Thanks for reading,