The .net guy started a discussion on this topics so here is my experience/ideas on this.

Unit Tests

I could not live without them :). Since I read Fowler‘s book about refactoring I’m using unit tests everywhere where I have more than 10 classes both at the company as at home.

It’s panic when the number of features without unit tests increases
(lack of time, or very urgent things to solve, I know unit tests first
…). It’s relief when you are fully covered. What I like most about
using unit tests is that it gives you really speed. You can hack freely
and at the end if the unit tests pass you are OK, ready to make the
commits.

It is not universal panacea but it really eliminates the small and
medium bugs, and seriously prevents introducing new bugs while
changing/refactoring things.

However it does not eliminate complex bugs (the hard to catch and
fix type) but even so once those are fixed prevents them from
reappearing.

This is from experience, not theory. I use tests for over a year
now, and I wouldn’t go back. I can not imagine a stable medium or large
project without unit tests, mainly because I don’t believe it could
exists.

Pair programming

Pair programming does wonders for the code and most of the time for
the coders to. It’s an excellent idea with excellent results and with
only one but. The human factor. It’s very difficult to impose pair
programming in a team except for short periods of time, even if
everybody acknowledges the merits.

People everywhere have good and bad days, and pair programming
requires patience therefore doesn’t work very well when there are too
many bad days involved and that is basically the reason I have said
that it doesn’t work for long periods of time (At least I didn’t
managed to make it work in my company 😉

Still we are using it constantly and happily in the next situations:

• One team member has a too long dark period and seems unable to get
  out of it by himself. Making it work in a pair will get it back again
  in a maximum of two days, days in which is producing good code 😉
• There is some kind of knowledge transfer needed. Either you
  are new to a part of the code or functionality or you just want to pass
  one some best practices, pair programming does wonders.
• The needed functionality is a bit too complex and you are
  uncertain about your ability to make it in time at a wanted quality.
  Having a strong partner does wonders again. It’s an excellent panacea
  for “Analysis Paralysis” 😉

From experience a pair produces more than two individual programmers
at a lot better code quality. Sure there are exceptions, but that has
to do again with the human factor.

Who knows maybe in time will become the defacto way of coding, just
like coops use to work in pairs 😉 but that is a bit too far away as I
see it.