Code Oversight

1. Risks of solo programming

1.1. Tunnel Vision (a.k.a. Frog in a Well) Fatigue Higher defects Less knowledge transfer More distractions Less refactoring Weaker problem solving

2. There are no best practices

2.1. There are only the practices you are using now.

2.2. And practices that are better than the ones you are using now. -- Corey Ladas

3. Definition

3.1. 2 pairs of eyes have viewed code before check-in

3.2. Team ownership

4. Option 1: Pair programming

4.1. 2 people working as team

4.2. Overall time 15% more, repaid in shorter & less expensive testing, quality assurance, field support

4.3. Better designs, shared knowledge, team building, enjoy work more

4.4. Many styles: ping-pong recommended often

5. Option 2: Peer programming

5.1. Do some work, another dev must review and check-in

5.2. More time to explain, delay in reviewing, onus on reviewer

5.3. Coding can still be solo

5.4. Email pass-around – Source code mgmt system emails code to reviewers automatically after checkin made.

6. Option 3: OSS committer model

6.1. Do no harm principle

6.2. Commits reviewed by core team

6.3. Partial commit access an option

6.4. More suited for large teams

7. Option 4: Formal code review

7.1. Meet and review code line by line

7.2. Least fun, most tedious

7.3. Longer delay between written code, reviewed code

7.4. May not find more bugs than less formal reviews