Welcome to the The Art of Agile Development website. Think of this as the "special features" DVD for the book, only without the DVD. (If you haven't bought the book yet, that's okay... we won't tell if you don't.) Here, you'll find a cornucopia of bonus material, such as downloadable posters, behind-the-scenes material, and new insights.

For more bonus material, see the table of contents. New entries are posted most Wednesdays.

(If there's nothing else on this page, this chapter has yet to be posted. Try the table of contents instead.)

 Print

The Art of Agile Development: Collective Code Ownership

27 Aug, 2008

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

Inside the Book

  • 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


Loading...

Loading comments...