I usually follow the news in the agile world on infoq, and I like the feature whereby you can listen to selected conference presentations online. This week I was making some biscuits one evening, so I took the chance to listen to Linda Rising talking about “agility: possibilities at a personal level”. I have to say I was rather disappointed. I think her material was not that relevant to agile in the first place, many of her claims lacked credibility, and although the talk was superficially entertaining, it did not supply useful insights or conclusions. This provoked me into leaving a comment on the infoq site. I wonder if anyone will notice.
I’m looking forward to Europython in Birmingham at the end of June. Geoff and I are going to be rather busy at it. They’ve just published the programme, and between us we are holding 5 sessions. I’m running a “coder’s dojo“, a “clean code challenge”, and Geoff and I are doing a tutorial on texttest together. Geoff is also giving talks about texttest and pyUseCase.
The coder’s dojo session is a copy of the original XP2005 workshop by Laurent Bossavit and Emmanual Gaillot, only in python with different Katas. The structure is the same though – introduction, prepared Kata, randori, retrospective. I thought it worked really well in 2005, so why change a winning format?
The clean code challenge is an idea I came up with. I’ve written on this blog before about KataArgs, and my dodgy python translation of Bob Martin’s code. I’m interested to know what the python community will make of it. I’m basically planning to throw this code out to anyone who turns up, and ask them to refactor it into better python. I’m of course hoping they will produce some innovative, beautifully pythonic solutions, and show me what clean code looks like in python.
The tutorial on texttest is essentially similar to the one Geoff and I did at Europython in 2005. It’s longer though, a half day, and builds on all the experience we have had since, doing tutorials at XP2006 and agile2008 for example.
All in all, I hope we’ll have some time and energy left to go to the other items in the programme. It looks like being a busy conference.
As I wrote in a previous post, I am organising a workshop at XP2009 called “Test Driven Development: Performing Art”. I am very pleased to announce that I have four pairs of expert programmers willing to perform prepared Katas at it! You can read about it here. I am especially pleased that all the performers are experienced coders with previous involvement in coding dojos in places such as Stockholm, Linköping, London, São Paulo and Helsinki. I think we’re going to have a great afternoon on 27th May.
Recently I’ve had the priviledge of working with a team of developers where I sit in the same room as half of them, and the other half are in China. My role is to help them to develop a suite of automated system tests alongside the production code. After a few month’s work, we now have quite a substantial product, with quite a substantial test suite.
When we started, very few of the developers had written much in the way of system tests, and even fewer knew how to write good, maintainable ones. Over the weeks, I have been promoting practices to enhance test readability, reviewing test code, and pointing out areas that need better coverage.
I’ve noticed that with the local developers, reviews and feedback are usually conducted face to face, informally, whereas with the offshore developers, it all goes via email, with a substantial time delay. This has meant that the Swedish developers have learnt faster, since they benefit from shorter feedback cycles, and a richer form of communication. Having said that, the Chinese developers are doing nearly as well. They seem really motivated to deliver what I ask for, and keep requesting and responding to feedback until they have written what I consider to be some pretty good tests.
It’s not all sweetness and light, however. As much as learning the technical skills of writing tests, the team needs to learn the culture of maintaining them. The CI server complains the build is broken far too often, and it is because the developers generally are not running the tests before they check in. My perception is that the offshore developers are worse at this, and my interpretation is not that they are somehow less good developers, far from it. I think that they just don’t have the same management support to spend time on maintaining the tests as the onshore ones.
Management in Sweden has really bought into the idea that investing in automated tests pays off over the long term, and vigorously support me in discussions with recalcitrant developers. Management in China has not. My impression is that they see only the costs associated with writing, running and maintaining automated tests, and would rather hire some (ridiculously cheap) Chinese students to run manual tests instead.
I would like to believe that this automated test suite is a really good investment for the future of this product. My experience tells me it should enable regression bugs to be found very soon after insertion, and enable much more frequent product releases. (You don’t have to wait for a 6 week manual test cycle before each release). Over the many year lifetime of the product, this should significantly outweigh the initial investment we have made creating it, and the ongoing costs of keeping it running.
The reality may be quite different. Future versions of the product will likely be developed entirely in China, and I suspect that without their Swedish colleagues’ enthusiasm, the Chinese management might decide the test suite should be quietly dismantled and left to rot. That may be the right economic decision, although it makes me weep to think of it. All I can do is console myself with the thought that at least the tests are so readable they will be easy to convert into manual test cases detailed enough for dirt cheap unskilled Chinese students to perform.
I’m looking for some really good coders. People who can write outstanding code, and yet know that however good they are they can always get a little bit better with a little practice, feedback and reflection. The kind of coders that attend a coding dojo and practice on code katas.
Interested? Could be persuaded to attend XP2009? Take a look at this call for participation.
