Two Sets of Eyes
Anything that goes into the product must be reviewed by two sets of eyes. We never want a single person to be the only one who understands why a given file was changed, or why something was removed. We introduce a bit of redundancy and help remove knowledge silos by including a second person.
Do not think of this as a pass/fail gate. Instead, it’s a learning and teaching opportunity.
- Code can only be updated by the developer who wrote it.
- Code can only be updated by the last developer who edited it. You touched it? It’s yours now.
- The thought of a developer leaving brings on cold sweats.
- The team has well-known knowledge silos. Only Jim can touch this area. Only Sue can work in that. This causes frequent schedule bottlenecks.
- A key developer pushed in a key fix (usually late at night), then went on vacation. The fix isn’t working quite right and no-one understands what it’s supposed to be doing.
- The product is plagued by quality issues that are often small things, and are easily fixed. But they shouldn’t have slipped into the product in the first place.
- Several developers on the team are known for introducing new toolkits and generally being quite clever. In fact, they’re so clever that they’ve solved the same problem multiple ways. All of which are in production.
- Huge gaps in expertise between team members… and it’s not getting any better.
- Transparency leaves no place for bugs to hide. Explaining your code to a second person frequently exposes issues that are difficult to see on your own.
- Illuminate misunderstandings before they become wide-spread and entrenched. When someone is resolving a solved problem, the second person can point this out and help eliminate the redundant work.
- Explaining your motivations and thought process to a second person ensures others understand your work and lower the odds that the work will become a boat anchor around your neck.
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- Explain both pair programming and peer code reviews to the team
- Give them a week to think about and read about the practice
- For four iterations, all version control checkins must contain the name of the second person
- Back out commits without a second set of eyes
- For iteration 1 & 2, all work must be done with a peer code review
- For iteration 3 & 4, all work must be done by pairing
- If possible, include team members (from other teams?) with experience
- Conduct a practice retrospective. What worked? What did you like?
- Did the practices slow you down?
- How many little things did you spot? What bugs were detected?
- What did you learn from working with others? New editors? Toolkits? Tips and tricks?
What Does it Look like?
- Pair programming
- Peer code review
There are two common ways to get a second set of eyes. One is the peer code review and the second is pair programming.
The peer code review is a lightweight, informal event. When something is complete, walk around and look for a team mate who’s not deep into a problem and ask if they’re available. Then sit with them, walk them through what you were trying to solve, then show them the code. The process is similar for graphics, automated tests, an so on. This is an interactive process with discussion as you move through the work.
When you’re done, ask what they think. If they don’t understand what you’ve done, or think the solution has fatal flaws, revisit your work and try again. Remember, as a reviewer, don’t reject work because it doesn’t suit your own preferences, but only if it’ll cause serious problems.
Pair programming is more involved. Two people sit together and work on the same problem. There may be two keyboards, or a single keyboard may be passed back and forth, but everyone is looking at the same screen. There are several styles, but there’s a lot of high bandwidth communication during the entire process. Perhaps one developer drives the coding more at first while the second person is thinking through the story to ensure you stay on course. Both people share a single proverbial brain, working towards a common goal.
This is an excellent way to share work habits, mentor junior developers, or hone your own skills by slowing down enough to explain your thought processes to another person.
Again, do not think of this as a pass/fail gate, but as a communication/learning event.
- Fearing the second set of eyes
- Always getting the same set of eyes
- Waiting weeks or months before sharing
- Rubber stamp code reviews
- Using an electronic tool to queue up reviews instead of talking to your teammates
- The fastest typist, or loudest mouth, wins all the discussions
- Aggressively rotate reviewers. If reviews aren’t random, put a grid on a white board and work your way through the team
- Put the reviewer on your check in message
- Switch pair programming partners daily. Then every half day.
- Switch roles with your pair programming partner every hour
- Do peer code reviews with people who don’t know the programming (or testing) language you’re using. Writing code or tests that others can understand makes for much better product.
- Review code before you change it. Spread the knowledge about existing code, brainstorm on new ideas before recoding.
Exercises to Get Better
- Review languages and projects you don’t know or aren’t familiar with
- Review partially completed work to help you find better ways to solve problems
- Pretend you have a certain person reviewing your work. What improvements would they suggest? Can you do a virtual review without that person present?
- The goal is not the review. The goal is the interaction and conversation. How can you learn more or draw more out of your next review?
How to Teach This Practice
Ben Franklin said to make a friend, ask a favor. When you complete a task, walk around and find someone who’s not deep in their own code and ask them if they have time to review your work. You’ll find that modeling this behavior will lead to adoption.
After the team has had time to acclimate to the idea, make it a required part of every code check in. Before the code is shared, get a second set of eyes on it. If the code is written while you’re pairing with another developer, you’re covered. Otherwise, get a peer code review first. Put the reviewer’s name in the first line of your check in message.
How To Fail Spectacularly
- Gathering your entire team for every code review. Make these fast and lightweight.
- Saving up weeks and weeks of development work for a single review. If it lasts longer than 30 minutes, you’ve probably waited too long.
- Refusing to include interested team members. Occasionally you’ll work on something so intriguing that multiple team members will ask to be included. Have a group review in that case so everyone who wants to learn can sit in.