Unit Tests & Pair Programming
April 8th, 2002
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.
Entry Filed under: Software Development
