Developers work best when they work alone, but there are a few instances where collaboration brings better results - namely peer review and pair programming.
Peer review is when a developer finishes coding and gives the code to someone else to examine for defects or improvements. The code that gets through the peer review is of higher quality and has fewer bugs - which means lower costs in the long run.
It’s much cheaper to fix a bug before deployment than to spend time documenting the bug, entering it into the backlog, deciding on its priority, and then figuring out how the code works in the first place.
If you’re very particular about what goes into your codebase, code quality improves. If code is rejected and goes back to In-Progress, people will grumble at first. As you work more and more, code acceptance on the first pass becomes a matter of pride and people will do their best to produce clean, maintainable, well-designed code. That is, if the management values quality over deadlines in the first place.
Code review does take some sacrifice. Because another developer goes through the same work, they don’t produce code of their own. This means you get less done in the short run, but you save the project from work down the road. It’s an investment that pays itself many time over in the future.
A good solution to the productivity problem is to make developers pull tasks from a Code Review task list while they wait for QA (as they can’t pull more work due to WIP limit).
A problem with peer review is, because it takes time for someone to review new code and get familiar with it (especially if it’s a major feature), a reviewer tends to skim and make very general feedback. Later, when they actually get to work on the code, they’ll have lots of feedback and suggestions - but it’ll be too little, too late.
Be careful when you introduce code reviews to developers who didn’t have them before. A harsh review can destroy a person and sink morale. Once you do it a few times, people will be more open and will appreciate it as a chance to learn and grow. You just need to make sure to soften the blow until they get to that stage.
Code reviews aren’t the same for every task:
- Some need to be big and official, like when you’re releasing a big feature or a new module.
- Some are minor, like when you fix a bug and a fellow developer just needs to run a quick check.
Another collaboration tecnique is pair programming, when two developers work on the same computer, sharing keyboard and mouse. It’s much more collaboration-intensive. One dev is the driver and the other navigator, and they switch roles as needed. One is writing code and the other is reading and checking it while thinking through problems and what to do next. If one person gets stuck, the other is there to take the wheel.
Advantages of pair programming:
- people with different expertise can attack the problem from multiple angles,
- people learn new things as they show each other neat tricks and workarounds,
- more people know the code and can maintain it in case one of them leaves,
- the code gets written quicker, has fewer bugs and code smells,
- people who work together are less likely to procrastinate,
- it builds morale and interpersonal relationships, which make people enjoy their job more,
- there’s less wandering off down blind alleys, losing focus, and banging head against a wall.
Challenges of pair programming:
- bad in big doses as spending 8 hours working together is too fatiguing,
- it doesn’t work when people’s personalities or motivations don’t match, eg. when a low-skill dev who doesn’t care is paired with a senior dev who takes over the process,
- it’s hard to convince management it’s a good investment when all they see are doubled hours for the same work.
It’s also good for risky and experimental projects that are too complex for one person; or if you have a very complicated debugging process, and you need to have another person thinking why something doesn’t work.
Everyone should do code review. Pair programming, on the other hand, should be done from time to time and only if the situation calls for it.