In any software engineering project, there is code. These days, most software engineering projects also involve many people. Sometimes, in spite of efforts towards orthogonality, more than one of these people must work on code in the same source file. This is a merge conflict.

Aside that, there is the simple matter of synchronizing the existence of code that one person creates that another does not have. Simpler to solve, but equally important to progress as the merge conflict.

Sometimes, we do not give sufficient information to the source control system to unambiguously resolve a merge. In Subversion, this is the conflicted state.

What do we do about the conflicted state?

We take steps to avert a conflicted state:

• Commit early; commit often.
• Try to work on different parts of the code. Different modules, different files, or even just different methods.
• Mock objects. This is one of the least-utilized but most powerful conflict-avoidance practices.

In spite of this, almost every team eventually experiences a merge conflict. Methods for dealing with this vary:

• Destroy one person’s code, usually the one with less lines.
• Hand-pick lines to include from the merge and mark resolve (this is remarkably rare)
• Revert.

Usually, merges conflicts are surprising because of when they happen. Usually, it is a late night or early morning where the last committer is nowhere in sight.

To keep that person from being helpless, source control systems allow a comment to be attached to each commit of files.

Opportunity Abound

By making your commit messages useful, you can do more than save that hapless conflicted soul. By writing good messages, you enhance intrateam communication. ALERT: SPOILERS AHEAD. The one command you need to be an effective coach or team member is…

svn log

Use it during standups to remember just what exactly it was that you did last team time four days ago. Understand why 17 lines of code are gone from a file. Understand that Page X’s improper rendering is a known bug.

Bonus

The real bonus of having a quality source control log is that you have a concrete answer to the invariable coach question, “How is everything going?” They might (hint hint hint hint) even get involved enough to read the logs themselves, perhaps (hint hint hint hint) using a tool such as trac.

I honestly believe that on a day-to-day basis, barring new client information, a tool like trac coupled with excellently-written log messages can eliminate the need for a verbal standup for the team and for the coach. That, of course, depends on the definition of “excellently-written” log messages, which I’ll cover in my next entry. In the mean time, feel free to tell me why I’m wrong. 🙂

I can’t remember exactly when the Pair Programming bug started biting around Design Studio, but a first glimpse was given by Dan Cromer and (I think) Kevin Mehlbrech during my senior year. It was just another exercise for class, it seems, but for whichever reason – propaganda or awareness – it caught on this year in a form.

But pair programming as it has been done in Design Studio makes me nervous.

Observations

1. Pairs are often established for an iteration timeframe.
2. Pairs are often established between a person of high expertise and a person of low expertise.
3. Pairs do not switch roles on a regular basis.
4. Pairs tend to switch among (graph-wise) cliques within the team.
5. Pair programming is sometimes used when it is unnecessary for the task.
6. Pair programming roles are not followed.

My Interpretation

1. Iteration Pairing: This can work, and if iterations are short, may be the way to go.
2. Expertise Disparity: This, I believe, is generally highly detrimental to learning on behalf of both parties and reduces the output of the team.
   • Two expert people will push each other to a higher level.
   • Two novice people will learn at a pace that is suited to them – they will avoid having terms thrown around that go over their head and the inevitable “just let me do it” moments that kill learning and morale.
   • Disparity can work if the expert acknowledges their teaching role – that is, they must be patient and stick strictly to the pair role they have at any given time.
3. Not Switching: Buy 33 of these timers – 3 for each team – no pair will be without one. The switching interval really depends on what is being worked on, but something between 20 minutes to an hour is within reason. Providing some Command Adhesive strips to attach the timers to monitors temporarily would also help visibility and remembering to use the tool.



4. Cliques: This might be helpful in some circumstances. The cliques that form aren’t necessarily the social kind – it seems they form around interest in a particular aspect of the project or a specific technology. The risk here is not having other members of the team involved with an area of the project, which I think is mitigated by having two team members with detailed knowledge of the area. (They may not ride in the same car.)
5. Unnecessary: Some tasks simply don’t require pair programming. If the technology is familiar and everyone understands what you are doing – a “time suck” type of task – then don’t waste a resource to sit there and nod.
6. Roles: Pair programming defines two roles: Driver and Navigator. These roles are exactly analogous to the roles in rallying: The driver controls the machine (in detail); the navigator (or co-driver, as they prefer and are acknowledged to be called) knows the overarching plan and assists the driver with the necessary instructions.

Epic Digression: Driver and Co-Driver

Rallying is a form of motor sport using stock or near-stock street cars. The courses traverse public roads, gravel roads, dirt roads, snow, and desert. Unlike other motor sport, the routes are generally not circuitous – that is, they do not perform laps of the same course in continuous succession. Instead, it is a timed race from point A to point B – stages can be up to 20 miles long. Obviously, they’re moving quite fast, and generally, they have only driven the route a few times before. For that reason, the driver depends on the clear, concise, and precise pace notes of the co-driver. When you’re moving 150 miles per hour, it’s very important to be in sync. The co-driver watches the road to match with his recorded notes and adjusts his timing to the conditions. The driver, then, is focused completely on how to get the car through the described path as fast as possible. The driver is concerned with the implementation details of that path: gear changes, steering input, avoiding obstacles, adjusting to different surfaces.

This just-in-time approach of both implementation and direction is, it seems, at the core of pair programming as well. An important note: the co-driver generally writes pace notes ahead of the event. Analogously, the pair programming co-driver should have an over-arching plan (perhaps a story) with some details (perhaps tasks) in place before starting. The details can then be adjusted on-the-fly by the driver.