This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, . My blog is now at .  See you there!

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....


  1. I think there are no correct answers, as it all depends on the way your mind works.
    If you're a kind of "logical"/"analytical" mind, test-first will probably be good.
    But, if you're a kind of "exploratory"/"creative" mind, test-after will work better; you can obviously force yourself to test-first, but I guarantee that will never feel quite good.

    That's why I think companies should never force programmers to work test-first or test-after (well I've never seen any company forcing the test-after habit, probably because no zealot came out with a cool name for it), but rather concentrate on use cases, quality and obviously tests which could confirm both.

    Cheers and good luck with your interviews ;)

    Sergio B.

  2. I'm not sure you're correct to assume people pair-fix on production issues becasue it's the most efficient/practical way to do it. I think there is more psychology involved. Often a critical issue can only practically be dealt with by a single person (one keyboard etc.) but it makes the rest of the team feel like they should be assisting and having an 'assistant' takes some of the pressure off the 'fixer'.

    1. Agreed that it's not always the case, but in all the examples I've been given it was explicitly stated that it was because it was the best way to fix it - this is in organisations that do not do pair programming, but they state that the quickest way to get a critical problem fixed is to pair on it.


Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Dissecting the Disruptor: Writing to the ring buffer

Dissecting the Disruptor: Demystifying Memory Barriers