Oh, the Coder and the Tester can be Friends, can be Friends...

(with apologies to Oklahoma!)

Elisabeth Hendrickson just tweeted about a thought-provoking analysis by Michael Bolton of the much-vaunted Continuous Deployment at IMVU.

I'm a big fan of TDD, Automated Tests and Continuous Integration, but I'd hate to develop without help from good Testers. A couple of years ago I worked on a dream project; a very small, highly skilled team which included a couple of developers, a tester and a business analyst. We were pair-programming, and my pairs came from a pool that included some of the best agile developers in the UK. The Tester and Business Analyst were also outstanding.

Our defect rate was very low: five defects in UAT, none in production over a twelve-month period. There's no doubt that this was a team effort; the Tester and the BA both caught many defects that were caused by problems we developers hadn't though of, and therefore never tested for. Equally, the developers tested so thoroughly that the Tester and BA could focus on the hard stuff, where their skills contributed maximum value.

For reasons that need not concern us, the application initially went into production on a machine that was controlled by the developers. We could have done continuous deployment, but we didn't. We always asked our Tester to do a final check-through on our staging box; mostly he found nothing, but once or twice he found defects that would have been real embarrasments in production. Of course, that wasn't his only contribution; our acceptance tests were the product of very close collaboration by the whole team.

So it was no surprise to read to read about Michael Bolton's experience when he did some manual testing of the IMVU site. IMVU practise Continuous Deployment, and claim to rely entirely on Automated Tests. Read Bolton's 50 Deployments A Day and The Perpetual Beta and see the consequences.

EtherPad - real-time collaborative text editing

A tweet from Eric Mack just pointed me at EtherPad.

It's a free tool for real-time collaborative text editing. As Eric says, it's simple, and it just works.

If two or more of you need to collaborate over the web in real-time on a text document, this is all you need.

Refactoring is much easier...

Refactoring is much easier when you have clearly expressed intent.

This came up a few days ago when I was talking with Steve and Nat.

We were holding a lunchtime retrospective about the latest delivery of our TDD course.

We talked about what had worked well, what we could do differently, and how we could customise the course for audiences with differing requirements.

Nat and Steve were keen to develop an exercise that would focus on refactoring. I liked the idea but I also wanted to keep an existing exercise which brings to life the value of intentional programming.

I felt that the ability to express intent was even more fundamental than the skill of refactoring.

It's risky to refactor unless you can check whether the code still does what is wanted. I don't think you can do that easily unless the tests and code express intention.

Nat reminded me that what you express, and how you express it, is different in code and tests. Good tests remind you of intent when they fail. This makes it easier to diagnose the cause of failure.

Refactoring is easiest with clean code, and clean code expresses clear intent. (Of course, as Steve pointed out, everything is easier if you have clean code).

You might refactor because the intent is not clear, but there are other reasons to do so. For example, you might refactor in order to make the code easier to change.

"The ability to pay back debt...depends on you writing code that is clean enough to be able to refactor as you come to understand your problem"

Ward Cunningham - Debt

Conclusion: we will develop a module on refactoring, but we'll keep our emphasis on writing clean code and tests that clearly express intent.