Or flavour if you prefer...

I was recently speaking with another developer on a customer site about merging two projects. There is a new project which overlaps quite nicely with what his project does and many of the new requirements are "nice-to-have's" on his project. It seems to make quite a bit of sense, so now all the stakeholders are evaluating this path, but something he said struck me. Paraphrasing, he said "having a second person involved will prevent me from re-architecting it so often. I jump at the flavor of the month." Don't get me wrong, I like the guy, but... Arg.

I think this goes back to Joel Spolsky's Things You Should Never Do, Part I (April, 2000) where he serves up Netscape grilled with a side of fries:
Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

Almost every developer has been inspired to do this. The first time they start working with Design Patterns. The first time they played with Ajax. Their second project. Whenever they join an existing project and/or have to support an old project.

Before you try to grill me up, let me say that there definitely are times when code, architectures, widgets, operating systems, etc should go back to the drawing board and have some of the fundamental concepts reviewed. No matter how great a system is, without regular review, cruft, junk, and bad ideas slip in and infect the code but this must be done deliberately and with specific reasons. I'm not proud of it, but occassionally I still write temp code "because it works" with the hope of improving it later. Sometimes later actually comes...

Anyway, having a second person involved is going to disrupt how he currently does things. There will be some implicit code reviews, more questions asked, and - more importantly - someone else to coordinate with when architecture changes are desired. I believe this is one of the additional strengths of Pair Programming. Not only do the individuals push the pair along, but they also serve as a brake to slow the decision process and deflect the FOTM Syndrome..