“Collective code ownership” was coined as a term with the advent of eXtreme Programming (XP), although it most likely predates XP. The idea is that any team member can and should contribute code to any part of the project. Beyond that, each team member should feel responsible for the implementation of the project. This blog post will discuss the need for and the benefits of collective code ownership, as well as, methods for increasing a team’s level of collective code ownership.
Team Members Leave
An inevitable part of working on a team is that members leave. Whether it is temporary (i.e., sick, vacation, etc.) or permanent (i.e., roll onto another project, leave the company, etc.), there will come a time when someone may no longer be able to contribute new work or maintain past work on a project. In a more traditional approach, that transition time is spent frantically picking that team member’s brain for undocumented knowledge and pouring over code they have authored. No one especially enjoys this process, so why not try to avoid the need for it in the first place?
Team Members Get Too Clever for the Team’s Good
I am reminded of a time in my past work history where one team member claimed ownership of a Scheduling module for a system. There was nothing fancy about the Scheduling requirements at the time of implementation: the scheduler had a need to run processes with regular frequency (daily, weekly, monthly), at specific times, once, or on demand. There were requirements in the backlog for future needs for the scheduler, but they didn’t seem too complex. This team member worked in isolation for several sprints before announcing that he was leaving the company. The activities mentioned above regarding knowledge transfer commenced. To my surprise, I discovered a huge pile of multi-threaded, timer-driven spaghetti code that was clearly not maintainable by anyone not part of the implementation. It was also not finished, which in retrospect was good for the team. The team wound up having to completely re-write the scheduler after the original author left. As a result, we all learned a valuable lesson – collective code ownership would have prevented the original problem. The new scheduler was written in pairs (more on that later) and was well understood by multiple members of the team.
Team Members Get Pigeon-Holed
That’s not to say that team members should be generalists in technology or system knowledge. People tend to specialize in or favor certain technologies or areas of the system, and that’s OK if and only if the team is adhering to the rule that no team member is fully-isolated or pigeon-holed. There are a handful of things that every team member should be skilled in, such as writing automated tests. For more on automated testing, take a look at Part 2 of this series.
Benefits of Collective Code Ownership
No part of the system’s implementation becomes so complex that only a single team member can maintain or extend it. The entire system is implemented with a more consistent style using common idioms and patterns.
No team member is reduced to contributing to only one vertical, horizontal, or cross section of the system. Every team member is effective on multiple parts of the system.
Team members tend to “try harder” during their initial implementation. When a person knows their work is being constantly reviewed and immediately worked on by someone else, it creates accountability for higher quality work. Each team member wants to be courteous to their teammates. They feel responsible for making the implementation as suitable as possible for other members also working on it.
Team members are constantly learning about new areas within the system, including implementation and business rules. Having a more holistic view of the system helps the team make better decisions about how the implementation should progress. Working on many different parts promotes the proliferation of good ideas. The more a team member learns from and improves on their current projects, the larger the benefit will be for the next project.
One of the easiest ways to promote a sense of collective code ownership is to engage in pair programming. This is where two developers sit together writing code. It typically involves sharing a single keyboard, mouse, and monitor while taking turns “driving” and “navigating.” While one is in control of the mouse and keyboard, the other is actively validating the implementation against requirements, standards, and style expectations. After one of the pairs has finished a requirement (or even part of a lengthy requirement), the other pair takes over the implementation effort.
The concept actually stems from the practice of code review. Most of us have participated in formal code reviews and frequent informal code reviews. Why do we review code? To verify that requirements are being implemented properly and that code is well-formed and maintainable, among other things. Pair programming provides a mechanism for constant code review.
Objections to Pair Programming
Clients may claim they don’t want to pay two people to do the work of one or have the team slowed down by two people working on a single task. What the client desires is for the team to produce high-quality software on time while also being good stewards of the funds they’ve allocated to projects. In fact, there are times when pairing has marginal impact. Low risk activities, such as simple tasks or tasks similar to work already done, probably don’t merit a lot of pairing.
A study by Alistair Cockburn and Laurie Williams was produced that documents the actual cost of pair programming (http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF). As it turned out, the actual increase in cost due to pair programming was about 15% over the same task done by an individual team member. The benefits of shorter delivery time and fewer defects, however, more than offset the cost of pairing.
When to Pair Program
I typically do not advocate pair programming on all assignments. Pairing is most useful in specific situations.
Pair when you are stuck. Everyone needs help sometimes regardless of how good you may be at problem-solving. As a team, you should determine your “wheel-spinning” time-box. I recommend no more than 20 minutes. If you are working on a problem and can’t solve it in 20 minutes or less, it’s time to pull in another team member to help.
Pair when a new part of the system is being introduced. In an Agile approach, the entire team should be a part of the system design so that each member has at least a high-level understanding of the planned implementation. Even so, when implementation of a brand new part of the system is started, it should begin with a pair of programmers. You want to ensure the implementation meets all requirements, and is done in a style that meets or exceeds team standards. Pair programming is a great approach to achieve those objectives.
Pair when a new strategy, tool, or design is being introduced. If you are the first person on your project to use Knockout.js, you should pair with someone else during the first implementation. A pair should tackle the first time a team decides to use Moq in their automated testing suite. Pairing for new technology usage is pretty straightforward, but more subtle examples exist as well. The first time the Template Method design pattern is applied in a project merits a pairing of teammates.
Pair when you are brand new. As a new team member to an existing team or with the formation of a brand new team, pair programming is a good way to ramp up system and style knowledge for all new people involved.
Following the guidelines above will help you adhere to the concept of good stewardship while maximizing productivity and quality of implementation. Overall, pairing is a very good thing. However, don’t take my word for it. I always encourage teams to implement small, incremental changes and observe the results. If the results are positive, continue with those changes. If not, try something else.
With regard to pairing, pay attention to when and why team members are pairing and observe the outcomes. If the pairing is empirically beneficial to your team, note the “when and why,” and make it part of common practices.
By this point, you should see the inherent advantages to collective code ownership. Eventually team members leave and someone will have to maintain their code. Team members are much more valuable when they can work in all parts of the system. The system benefits from the entire team having ready access to all of the best ideas and practices as they are applied to an implementation. One of the best ways to promote a sense of collective code ownership is pair programming. Even though there are some objections to the practice, it can be very effective when done in the proper context.
If you have questions or comments about collective code ownership or pair programming, be sure to leave them in the comments section below or send a tweet to @CrederaMSFT. If you missed the previous posts in this series, we recommend reading Part 1, Part 2, and Part 3. Check back soon to read more about the nuts and bolts of software craftsmanship practiced by Credera!
Transform your business operations with our Microsoft solutions