February 24, 2010

...Learn TDD with Codemanship

Code Metrics Show Convincing Picture Of Impact Of Peer-based Craftsmanship Coaching

I'm sure they won't mind my sharing this with you. I've been putting together a presentation for managers in TV Platforms at the BBC, where I've been running a Peer Group Learning & Assessment program to help engineers hone their TDD and refactoring chops.

It's been bubbling away in the background for about a year with 8 of their engineers, and is now rolling out to other peer groups, so by the end of this summer pretty much everybody writing code in TV Platforms will have been through the basic TDD practice regimen and hopefully successfully passed a gruelling practice-based peer assessment to demonstrate that they're truly in the habit of doing things like running the test to see it fail and not refactoring on a red light etc.

Anyhoo, for the presentation, Kerry Jones - TV Platform's key technical design authority and a thoroughly good craftsman in his own right - threw together some code metrics to give us a picture of the "before" and "after".

It's looking good, I have to say. Remember this is data culled from projects in which only 8 of the engineers have been through a TDD PGLA exercise - that's about a quarter of all the TVP engineers.

Test coverage is up by about 40%. Method length and complexity has dropped by roughly 10-15%. Duplicate code has dropped by more than 50%.

Now, their stats were by no means bad to start with (the BBC have a much higher-than-average quality of developer, I'm finding), and it's usually much more dramatic when teams are starting from rock bottom (low-hanging fruit and all that), so these improvements are all the more striking. This is by far and away the most encouraging result I've had from a coaching program, and I'm quietly confident that as we delve into the murky world of refactoring and legacy code, and incorporate data on dependencies on OO goodness/badness into the picture, we'll see yet more improvements.

Whether project managers will give two hoots remains to be seen, but when we make the link between factors like test assurance, complexity and duplication and productivity and cost of change (already well-established through SEI, IBM and other studies), it's a picture that's hard to dismiss.

If you want to know what PGLA is all about, I'll be giving the lowdown at QCon on March 10th, and Kerry and I are booked in to talk about PGLA and software craftsmanship at the BBC at XP2010 this summer.

Posted 11 years, 10 months ago on February 24, 2010