I am Paul Wilson; Mere Complexities Limited, sells my consulting, coaching, and coding services. I am passionate about Agile, particularly Test Driven Development.
The P/J Divide
I was confused when I first heard an experienced and respected (by me anyway) practitioner say that he was attracted to XP because it provided an unambiguous set of rules that if conscientiously followed leads to the best in software development. It confounded me because it seemed to contradict much of what attracted me: its flexibility; people over process; embrace change over plan. Actually there is no contradiction: it's all about simple rules, emergence, and complexity; that's not what I'm writing about, though.
It's interesting that people who are mostly in agreement on details can feel so differently about the essence of XP. I think this is an example of
Micheal Feather's P/J divide.
On a
Radio 4 In Business programme I heard the divide described as "J types feel relief when a decision has been made; they can put that behind then and concentrate on other things; P types are relieved when a decision is not made; they don't like to close their options down". I think of it in terms of
Mary Poppendieck's "last responsible moment": "J"s are prone to premature decision making; "P"s tend to leave it too late.
What Micheal Feathers says about having a good P/J balance in teams is also applicable to the XP community, although as in teams the gap can cause friction. From listening to the arguments, I strongly suspect that the divisions over the new edition of
The White Book, mirror the P/J divide.
PS I'm "INTP".
PPS Posted this on the GNER traveling South for
XP Day. :-)
Agile Scotland Talk and Demonstration - Approaches to Story Testing With FIT
On December 5th I will be presenting on three different approaches to User Story Testing using the
FIT automated testing framework using worked examples for a simple web application. I plan to include the following topics:
- why use a specialist framework rather than xUnit?
- what kind of tests are appropriate?
- who should write the tests?
- how different approaches have different consequences
I hope to concentrate more on approaches to testing than the technical details of
FIT and
Fitnesse, but I will make the example code and a suite of tests available.
It was Brian Swan's
Automated Acceptance Testing talk in February (2005 despite the title) kick started my interest in "Story Tests"; I will try and include a few
Exactor examples.
Once and Only Once?
Some duplication issues at work.
Microsoft "TDD"
Microsoft's "TDD recommendations" have stirred things up: Alan Francis is
too shocked to comment;
Mike Feathers seems saddened; Ron Jeffries is
quite grumpy about it; Scott Bellware
is puzzled.
Kent Beck told us that his definition of TDD is
Test First Programming plus
Incremental Design: the Microsoft Recommendation is not TDD, but is it evil? To be honest, it's not far off how I started to Junit way back in '99 and I benefited from that. As a step on the road to TDD, it may not be so bad but as an end in itself it is dangerous: the greatest danger is that the benefits of post-design testing may not be sufficient to keep the coders. It's a small step from interface first programming to test after. Test-after takes you further away from Test Driven and closer to "test when (if) I get round to it" or "test after this release is out of the way".
Another danger to bulk test writing is that some tests may never pass. I once joined a project to discover that the tests were only running at about 75% success; the developer most responsible argued that the failing tests were a reminder of things to be done; his failing tests encouraged other failing tests in a classic example of
"Broken Windows". Refactoring, or even adding functionality out of one's own silo, was much more difficult than it needed to be as it was hard to tell if something had been broken.
Answering my own question
Many, many, times, and that won't be enough.
It's not reasonable to just tell people and expect to be believed. It's not about logic, either. Persistence, patience, and using multiple tactics
is paying off. And one of those tactics is "broken record".
Just venting a bit of frustration
I don't know how many times I have to repeat "The reason it is broken is because you didn't write any bloody tests" before it actually sinks in.
Multiple Choice Question
Your release procedure consists of a number of tasks that must be executed in order. For the second time you've forgotten one of the tasks; you need to roll back and start again. You should have:
- a clip round the ear
- a checklist as part of a documented process
- a script
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)
