• Next: Documentation
• Previous: Continuous Integration
• Up: Chapter 7: Releasing

in 99 words

With collective code ownership, everyone shares responsibility for code quality. Anyone can make necessary changes anywhere, and everyone is expected to fix problems they find. To make it work, let go of your ego. Take as much pride in the team's code as in your own code.

When working with unfamiliar code, ask the local expert to pair with you. If he's unavailable, infer high-level class responsibilities and method behaviors from their names, and rely on unit tests for further documentation and as your safety net. As you work, help the next person by taking opportunities to refactor.

Commentary

The Crucible of Great Teams

Section Outline

• Collective Code Ownership
• Making Collective Ownership Work
• Working with Unfamiliar Code
• Hidden Benefits
• Questions
  • We have a really good UI designer/database programmer/scalability guru. Why not take advantage of those skills and specialties?
  • How can everyone learn the entire codebase?
  • Doesn't collective ownership increase the possibility of merge conflicts?
  • We have some pretty junior programmers, and I don't trust them with my code. What should we do?
  • Different programmers on our team are responsible for different projects. Should the team collectively own those projects?
• Results
• Contraindications
• Alternatives

Full Text

This section will go online later this year. In the meantime, why not buy the book?

• Next: Documentation
• Previous: Continuous Integration
• Up: Chapter 7: Releasing