In a previous post about propagating best practices in code, we confronted the question “How do we build up best practices or established ways of doing things in the code?” The answer was a variety of communication techniques: code reviews, learning sessions, mentoring, pair programming, and documentation.
We can add another item to that list of knowledge management techniques: Communities of Practice (CoP). The wikipedia definition of Community of Practice is very general: “a group of people who share a craft and/or a profession.” If we wanted a CoP for purposes of propagating best practices in code, we could refine it to say that we want “a group of people who share a codebase, the group being created specifically with the goal of sharing knowledge related to that codebase.”
Imagine a group of developers for a project coming together on a regular basis to discuss the codebase. If people talked about their current work or gave short tutorials on different parts of the system, they would quickly eliminate the scattered word-of-mouth knowledge about how things work or how to make certain kinds of changes. Other topics could include issues in maintenance, upcoming architectural decisions with risks and mitigations, current work on a particular component and how that relates to the rest of the code, reviews of a component to bring it in line with existing best practices, and so on.
There are known ways to encourage the success of your CoP. They are listed on wikipedia but I’ve repeated them here with suggestions for practical implementation in this context.
- Design the community to evolve naturally: The group should be able to shift direction and focus as needed. Making this an explicit goal and allocating time for meta discussion on the group would be a practical way to encourage natural evolution of the group.
- Create opportunities for open dialog within and with outside perspectives: There should be free exchange of ideas between members of the team who have been there the shortest and the longest. Newer members have outside perspectives that can be brought up to compare with the inside perspectives, resulting in cross-pollination of the best ideas.
- Welcome and allow different levels of participation: There will naturally be high content contributors and low content contributors (who are there to absorb content from high contributors). Both levels are necessary for the group to effectively share information. To implement this, not everybody should be forced to contribute content. Contribution should be completely voluntary.
- Develop both public and private community spaces: If there is an online component of the group, private messaging should be possible. Regular private meetings should be encouraged.
- Focus on the value of the community: Again, meta analysis is important. If the group is not productive as it stands, it should shift focus (per previous note) or be disbanded altogether. The purpose is to create value, not to have unnecessary meetings.
- Combine familiarity and excitement: Besides review of the familiar existing code, there should be brainstorming about new and exciting ideas for the technical direction of the codebase.
- Find and nurture a regular rhythm for the community: A regularly scheduled meeting instead of ad-hoc meetings would be good approach. Weekly would be a good place to start, possibly moving to bi-weekly if there is not enough content.
In summary: a regularly scheduled meeting of developers to just talk about the codebase goes a long way to propagating best practices. If you start a CoP the ideas here should give you a good place to start!