This document discusses mob programming and ways to reduce feedback loops in coding. It describes the author's experience with mob programming on different projects involving 3-5 co-located programmers and sometimes remote members. Key aspects of mob programming discussed are strong-style pairing with designated driver and navigator roles, increased ownership and resilience from the whole team working on the same thing, and benefits like more just-in-time design discussions. The author also notes some challenges of mob programming including less flexibility and that it can look unusual to outsiders. Overall mob programming is presented as an effective way to continuously learn through reflection on shared work.
4. “Review every line of code. A code review typically involves the
programmer and at least two reviewers. That means that at least three
people read every line of code. Another name for peer
review is "peer pressure." In addition to providing a safety net in case
the original programmer leaves the project, reviews improve code
quality because the programmer knows that the code will be read by
others. Even if your shop hasn't created explicit coding standards,
reviews provide a subtle way of moving toward a group coding
standard—decisions are made by the group during reviews, and over
time the group derives its own standards.”
5. “Review every line of code. A code review typically involves the
programmer and at least two reviewers. That means that at least three
people read every line of code. Another name for peer
review is "peer pressure." In addition to providing a safety net in case
the original programmer leaves the project, reviews improve code
quality because the programmer knows that the code will be read by
others. Even if your shop hasn't created explicit coding standards,
reviews provide a subtle way of moving toward a group coding
standard—decisions are made by the group during reviews, and over
time the group derives its own standards.”
25. Agile Software Development: The
Cooperative Game by Alistair Cockburn
Figure 3.1-1. Completed office layout
(Courtesy of Ken Auer, RoleModel
Software).
62. "For an idea to go from your head
into the computer, it MUST go
through someone else's hands"
63. Strong-style pairing
Driver
• At the keyboard
• “Smart keyboard”
• Trust your navigator
• Think the computer of the
Enterprise
Navigator
• Give verbal instructions to the
driver
• Talk at the highest level of
abstraction
Literally would look at the code from a different point of view
Guided katas at Ancestry
Basically a traditional “code along with me” workshop
Everybody could contribute
But didn’t get “pay off” at the end of something you started usually
Turn up the good
Additional monitors for build/electronic board
Moved desk
Switched to standing desk
Tried 8, 10, 12, 15 minutes
Too short and don’t “feel” like you did much as driver
Too long and you are away from keyboard too long
Physical connection to work
Move in an out of mob fluidly
Vacations didn’t require handoff planning
Meetings might derail a pair
More AND less important to identify the right thing at any given moment
Don’t worry about release coordination (as much)
Get small batches released quickly
Cycle time was consistently lowest on our team
Maybe not faster, but sooner