Two people put their workstations next to each other, so they can peer into each other's screens on demand.  They work on separate pieces of the software, as needed, but peer over to check code, brainstorm, and speak easily.

The next closest to PairProgramming without being that.
-----
What does it gain, what does it lose, compared with PP?
----
Something you lose in this discussion (and implicitly in some on the discussions of FullyParallelProgramming and PairProgrammingCostsBenefits) if that a team is probably more than two folks. One of the benefits of pairing is the rapid dispersal of knowledge through the team. This would be lost in the more static, two-by-two environment.
-----
The difference between SideBySideProgramming and FullyParallelProgramming would be just that.  What's being nominated here is that for a project of just two people, they will move noticeably faster and achieve ''almost'' as much quality as PP.  I don't think that the answer to that nomination is clear, one way or the other.

What's being examined on FullyParallelProgramming is a hole in the PairProgrammingCostsBenefits argument.  That argument says only that 2 people work 57% as fast as one... which opens the door to the speculation that if time to market is ''really'' important, the project should be subdivided down to the most granular independent bits and handy out to solo programmers (sitting in the same room, of course), thus picking up the 15% gain in time to market.  
(Dispersal of information is still rapid, but not as deep as in PP, but that's not the question).

''But only if there exists a good enough specification to allow these folks to work independently.''