I've worked with a number of teams that have a heavy resistance to pair programming. The resistence is typically justified using the argument that it seems like a waste of resources to have two people work on one task. I'm not one to dictate what practices a team should adopt (although I'm not afraid to share my somewhat strong opinions ;-), but I suggest considering these potential benefits of pair programming before deciding not to adopt it:

• Multiple sources of problem solving input avoids most instances of getting stuck.
• Multiple sources of problem solving input provides more solutions from which to choose.
• Partner can add element of parallelism (e.g., look up API method while pair compiles code).
• Partner continuously reviews work products for correctness, conformance to standards, etc.
• Partner continuously reviews process for conformance.
• Continuous review increases odds of catching mistakes, misunderstandings early.
• Continuous review reduces odds of lengthy pursuits of incorrect or inappropriate solutions.
• Allows sources of specialty knowledge to rotate and be available to more situations.
• Cross-training occurs at an accelerated rate (proportional to frequency of pair rotation).
• Mentoring occurs at an accelerated rate (proportional to distribution of pair partners).
• Decreases risk that individual developer mistakes will damage significant parts of the system.
• Reduces dependencies of specific individuals to parts of the system or technologies.
• Increased overall involvement enables higher degree of team self-management.
• Increases social interaction, camaraderie among team members.
• Common goals of pairs facilitates team building.
• Common successes shared by pairs increases team accomplishment.
• Increased sharing of responsibilities facilitates team culture evolution.
• Partner provides motivation to stay continuously engaged.
• Natural "competition" encourages higher performance levels.
• Partner provides sanity check for knowing when to take breaks or stop for the day.
• Reduces the need for expensive development workstations by half.

/Paul Hodgetts
Bookmark this link to this article.
Do you have feedback or questions? If so, please send us email at feedback@agilelogic.com.

Micro-focused refactoring is a strategy like hill climbing. When done well, it leads to the best (or sufficient) local design (peak of the hill).

The localized hill climbing strategy doesn't, however, ensure that you're climbing the highest hill. We may arrive at the best design for the given context (the peak of the hill), but not at the optimal, or at least an overall acceptable, design (highest hill). (This is referred to as a "local maximum.")

If the wrong hill is chosen, there is some cost in retracing our steps back down some or all of the hill (rework). The higher the hill and the more we climb before noticing there are higher hills, the greater the added journey to get to the better hill (the more complex the problem and the deeper into the implementation we get, the more the rework costs). We can only hope we don't run out of daylight before we can climb back down and ascend the better hill (analogy left to the reader ;-).

Macro-focused design is a strategy like hill searching. It provides a better vantage point to look for the highest hill (optimal, or at least better, design).

However, we need to have a good view of the mountain range (context) in order to search for the highest hill. If we have a clearly known context, with a known set of hills to search (known set of design solutions, a.k.a. patterns), we can find and choose the optimal design solution/pattern (hill to climb).

Because of the cost of retracing our steps (rework), and the amount of daylight left (resources), it's a good idea if we can find a vantage point and scan for the higher hills before we start climbing. We could save a lot of climbing and retracing this way. By recognizing the obvious contexts of our problem, and by researching the canonical solutions (patterns), we can significantly reduce the risk of rework.

If we don't have such a well defined context, with canonical solutions, then searching for the highest hill can be speculative and a waste of time. In these cases, it's probably better to just pick the highest hill we can see and start climbing. Maybe on the way up we'll notice a higher hill (learn something new), or determine we're on a good hill after all (good enough). But there's really not many hills that haven't been climbed these days.

Once chosen, the highest hill is still climbed a step at a time (with a micro-focused, test-first refactoring strategy). We take the most direct route, pausing for refreshment as needed, and stop when we reach the peak (sufficient solution). It's a good idea to stop occasionally and take a look around as well, just in case there's a higher hill that's appeared over the horizon. Sometimes we find that the hill has a little slope attached to another hill, and we end up on a different hill than we thought we would at first.

When hill searching, the ideal case is to choose the best hill (optimal design). But we also want to be conservative in choosing. There's no point in choosing a 12,000 ft. hill when we only need 9,000 ft. of altitude. The design choice should be the simplest, but sufficient, one that fits the known requirements.

Especially when there's uncertainty, either about the context or requirements, choosing smaller hills (simpler designs) reduces risk. If the design turns out inadequate, there's less to rework. If it ends up doing the job, it should be one of the simpler (and cheaper) solutions, and we win for doing less climbing (work).

When there's great uncertainty, we can just start climbing any convenient hill, one small step at a time. As we climb, it would be prudent to keep scouting just how high the hill we're climbing really is, and if there are any promising adjacent hills, before we get too far up. If we need to, we can always send up a lone climber to check out the route before we send the whole expedition up there (design spike). Being adaptive means being able and willing to change course, even double back, at any time (that courage thing).

Climbing in pairs can reduce risk. While one climber is focusing on the hand holds and making sure the ropes are secured, the other can be scouting the route and scanning the horizon for better hills. When things get dicey, they can consult. If one climber slips, the other can grab the rope and pull them up.

/Paul Hodgetts
Bookmark this link to this article.
Do you have feedback or questions? If so, please send us email at feedback@agilelogic.com.