Overheard: Agile Truths

After attending a number of conferences and events, and performing numerous interviews, I'm starting to hear the same things again and again.  Since Dan North challenged all my assumptions at QCon, I'm reluctant to outright ridicule them, but I will put forward my personal opinion.

Note: these are things I have heard from multiple sources, so with any luck I am not breaking the sanctity of the confessional interview.

I've never pair programmed, but I've frequently worked with a partner on critical production problems
I find this fascinating.  If there's one thing that needs to be fixed as fast, as correctly, as efficiently as possible, it's a production issue.  And when there is one, "everyone" knows that two heads are better than one, even The Business.

If this is the case, why is it so hard to sell pair programming as the default state of affairs?

Is it because creating new features is seen as just typing, where the bottleneck is access to the physical keyboard?  Is it because fixing defects when the pressure isn't on is suddenly easier for one person on their own without help?

This state of affairs is interesting to me as it implies that when proverbial hits the fan, the instinctive thing to do is to work collaboratively.  Why don't we do it more often?

We use Test Driven Development to get coverage
Seems weird to me to write your tests first to get coverage.  If unit test coverage is your most important metric (and other people have covered why this might not be the case), I'm not sure why you would write your tests first.  Seems to me that you'd get better coverage writing the tests after the code.  That way you can be sure you've covered every eventuality.

To me, the statement implies two assumptions which I would challenge:
a) The primary value of writing your tests first is to meet your coverage requirements
b) Coverage is a meaningful metric

TDD/BDD has a number of benefits (...and now I'm reluctant to list them here in case people repeat them back to me in an interview).  Good coverage will probably be a side effect of being forced to write your tests first, but I'm not convinced that's the best thing that will come out of using TDD.

I only test first when I know what I want to code
I've overheard people saying that they test first when they know what the code is going to look like.  So you dive straight into the code when you don't know what you're doing???

Of course there is a place for this - spikes, prototyping, getting a feel for a new library, so on and so forth.  But I feel that for most code that you write in your day job, you probably have a business requirement and possibly (probably?) a less firm idea of how you're going to code it.  To me, this translates into writing the test first (which documents what you want to deliver, which you already know) and then getting that to pass (which is writing the code, which is the bit you might not know).

If you know exactly what the code is going to look like a) I would question that statement and b) what's the point of the test?


What are the real answers?
At QCon I saw on Twitter a number of complaints because the presentations there gave opinions, guidelines, and, worst of all, a lot of "it depends".  But people seemed to want The Answers.

In my opinion, what developers get paid for is working out the "it depends" parameters and selecting an approach, technical or process-wise, that works for their situation.

So although I have strong opinions on all the above subjects, and although LMAX has specific approaches to both pair programming and automated testing, sadly I'm not going to go into lots of details about those.

Mostly because I'm still interviewing candidates, and I don't want to give away the correct answers....