Solo Partnering

What are your tricks for gaining the advantages of PairProgramming when your current situation can't afford you a partner?

Pairing with my other personalities (of course :-).

Seriously though, we all wear many hats: developer, tester, analyst, architect, even QualityAssurance from time to time. So when I deem it convenient for me, but before I've written too much code at one time, I look at the code while wearing a different hat from the one I wrote it with. Sometimes I do this instantly as I write a given statement. Sometimes I do it every block or so. But I really do it at the granularity of my own thought-flows rather than of lines and statements. It not a second pair of eyes, or even a second head or brain. But it does introduce new perspectives and concerns within the limits of programming solo.

Writing tests helps me think like my client, which is sure to force new perspectives on me...

Is ExtremeProgramming more effective than traditional programming techniques if you one have one developer, and thus can't do PairProgramming? One of Extreme Programming's strengths is that by Refactoring, we keep the design simple even as design and requirements evolve. But we can only refactor with impunity so long as we have confidence that this will not introduce new bugs. XP advocates on this site emphasize UnitTests and FunctionalTests as the primary ways of preventing this, but clearly the DesignReview/CodeReview provided by PairProgramming also plays an important part. Consider the following statistics (I'll look up the details later, but like nearly all such statistics, they probably come from CapersJones?; these numbers are what I recall):

• testing finds 30%-70% of defects
• reviews/inspections find about 60% of defects
• testing combined with reviews find about 90% of defects

So if we forgo pair programming, will the 300% increase of defects (from 10% to 30%) introduced during refactoring that make it through the process make constant refactoring a bad risk?

There is no reason whatsoever to believe that these figures would hold on a program with a full XP test net.

That may be so, but is that because a pair of people will come up with a more comprehensive set of tests? If so, then the solo XPer is still screwed, alas. Some other points that might be relevant, or even true (I'm an XP newbie myself, so it's hard to judge):

• The types of bugs introduced in refactoring are very likely to be found in unit tests or compiling (WhenIsManifestTypingConsideredaGoodThing).
• By keeping the code simple, refactoring reduces the likelihood of introducing new bugs.
• The actual process of refactoring can help you find bugs, by forcing you to look at your code in a different way.

-- AndrewSemprebon

---

Also see SoloProgramming and SoloProgrammingXpWorkarounds