My 'Technically Speaking' column article "Lessons Learned in Close Quarters Combat" has been publushed in the December 2008 issue of Better Software Magazine. The summary reads as follows:

Few would think that Special Forces tactics bear any relation to software project teams. But Antony Marcano draws a surprising parallel between the dynamics of modern Special Forces “room-clearing” methods and the dynamics of modern software development teams.

It begins as follows...

An Assertion-based (also known as programmer tests in Test Driven Development) Test Oracle (an information source of what makes a test correct) was developed 27 years ago, well before TDD was thought of but probably around the time test oracles were thought of. That was also long before refactoring was thought of, simplifying the logic to its simplest form.

It was designed by US history professor Allan Lichtman and mathematician Volodia Keilis-Borok. It is 13 assertions (that is refactored all right) that can each be true or false, and has picked every US federal election result since 1984. If more than half of the assertions are true, the governing party will win, otherwise they will lose. The majority of the assertions first went false in early 2006, at which point Lichtman said “Long before the nomination contest unfolded, the Democrats could take a name out of a phone book and still win.” I guess they must have used a Chicago phone book, or maybe even a Brazilian one! (where there are now multiple Barack Obamas) This year the test oracle has evaluated False, but if we look at it vice-versa, True or even Yes we can! [grin]

If the test oracle is correct, newspapers will print this mock headline on Wednesday the 5th of November 2008. (There’s another agile word, mock!)

In this quite long blog I’ll tell you how I approach agile projects and why I think it is the right way. In short my idea is very simple – I do write down „the test ideas” at the very beginning of the project, while developers are doing the initial work and I have nothing to test yet. I analyze whatever information is available and ask for more to do that. When I’m done with the list I save it and forget about it. I test ignoring it. It’s sometimes late in the project when I dig it up to wonder how much of the ideas are covered. A lot of them does not make sense any more, others are somewhat covered, but I keep discovering that quite a lot of things I have missed – and I discover more bugs that I would otherwise missed. Why? In a hurry, testing one feature after another I’ve missed the big picture – that’s why.

I'll be giving a free evening public talk in Clerkenwell, London for SkillsMatter on 8th September at 18:30pm. The talk is applicable to anyone on an agile team or running agile projects...

Testing is an integral and prominent aspect of agile development, however, new teams form and existing teams prevail with uncertainty about how testers fit into the process. Even those projects that don’t have testers dedicated to them can still feel there is a void in how they ensure that they are building the right product and building the product right.

Cross-functional teams are growing in popularity, influenced in no small part by the growth in adoption of agile values and the methodologies that support them.

Whether it's a side effect of getting developers and testers working more closely or due to the undulating skills demands from iteration to iteration, each team-member is increasingly expected to have more diverse skills. Furthermore, Test Driven Development increases the need for developers to know more about testing; automated acceptance tests as part of Acceptance Test Driven Development written in the same language as the product increases the need for testers to know about programming.

No, this isn't on the same topic as my previous post on Udi Dahan's interface naming style. But, I have taken inspiration from it as I've been trying to find a way to communicate a people issue.

In that post, I was illustrating a point that Udi had made about naming interfaces not based on what they are but what they do... based on their roles...