Categories
Agile Java Ruby

An issue with mock-driven development in dynamically-typed languages

First, let me make it clear that I really like BDD, I really like mocks, and I really like dynamic languages. RSpec does a pretty good job of combining all three.

However, there’s one disadvantage that duck-typed languages suffer when it comes to using mocks to drive the design of the interfaces between objects.

Categories
Agile

Avoiding pair-programming breakdown

One of the persistent themes in my team’s retrospectives is that we don’t pair as much as we should. It’s not that we don’t want to pair, or that something’s stopping us: we just seem too often to lack the discipline to start pairing and then not drift back into working alone again. I’m not sure the best way of avoiding the delay in forming pairs at the beginning of the day and after lunch1, but here’s at least one tip to keep the sessions going.

If you need to quickly nip back to your own machine to check some documentation, google something, check for some urgently-awaited e-mail reply or whatever…

Don’t take your chair with you.


1I think this is a variant of the ‘one more pint effect’ that’s often observed when a group over a certain size meets in a pub prior to going for a meal. One person decides that everyone’s going to take ages drinking up, so they decide to have ‘one more pint’. Of course, someone else then sees them with a full glass, and makes the same decision, and you end up arriving in the restaurant an hour later than planned. The pairing equivalent is where you all think ‘everyone looks busy, so I’ll just [answer that e-mail | do that pointless mandatory on-line training course | go and make a coffee] while I’m waiting for someone to pair with’.

Of course the real answer is to be strict about all production code being pair-programmed, rather than letting yourself make exceptions for ‘trivial’ tasks, or UI code, or refactoring, or something that started as a spike but has somehow grown tests and made it into the trunk…

Categories
Agile BT

BT Agile Awards final

The CSAM-n team receiving our trophy

Wednesday night saw the end-of-year BT Agile Awards dinner, with all the recipients of the various quarterly awards gathering at the Royal Horseguards Hotel to eat, drink, and find out who’d won the overall team and individual awards for the year. It was a good night, made even better by the fact that we won the team award! Our prize is that we’re off to the Agile 2007 conference in Washington DC in August.

Congratulations also to Gregg Wyburn for winning the individual award, and to our current colleagues from the .NET SDK team, who picked up their quarter three award for best application of the BT agile values.

More photos from the night on Flickr (see also photos tagged with btagileawards – hopefully some more people will post and tag photos, but BT’s webfilter blocking Flickr doesn’t help).

Categories
Agile

The Way of Testivus

From the slightly-odd The Way of Testivus, via InfoQ:

The pupil asked the master programmer:
“When can I stop writing tests?”

The master answered:
“When you stop writing code.”

The pupil asked:
“When do I stop writing code?”

The master answered:
“When you become a manager.”

The pupil trembled and asked:
“When do I become a manager?”

The master answered:
“When you stop writing tests.”

The pupil rushed to write some tests.
He left skid marks.

If the code deserves to be written,
it deserves to have tests.

Categories
Agile Rails Ruby

Are we spending more and more time writing tests?

A while ago I wrote about testing trivialities, and claimed that no matter how simple the piece of code is, it still ought to have a test. I followed it up with some thoughts on using a helper to simplify writing specs for common validations. Even using the helper, the actual test code for a single validation outweighs the production code by a factor of more than three:

Categories
Agile Java Rails Ruby Software

cruisecontrol.rb

In case you missed it, those nice people at ThoughtWorks released CruiseControl.rb yesterday.

Categories
Agile Rails Ruby

DRYing out model specs

[Updated 14/3/07: corrected specify_attributes as per Paul’s comment]
[Updated 18/12/07: modified to avoid crazy RSpec errors]

A week or so ago I wrote about writing specs for simple pieces of functionality (particularly those that are arguably just configuration, like Rails validations). I argued that it’s important to test-drive even the simple things – however, the amount of test code can get out of hand.

Categories
Agile Ruby Software

Testing trivialities … and double-entry bookkeeping

From time to time I end up in a discussion (as often as not with myself) about the point at which something is so trivial that it doesn’t justify creating a unit test (or behaviour spec, in more BDD-like language).

Categories
Agile General nonsense

InfoQ interview Mary and Tom Poppendieck about Lean

See the video here.

I’ll get round to watching the whole thing eventually, but first, use the link underneath the video to skip to “What are some of the other principles of Lean?”

I never realised that Tom Poppendieck was such an accomplished ventriloquist!

Categories
Agile Enterprise

Cultural blocks to adoption of agile development

A recent article in the New York Times describes the issues of introducing ‘The Toyota Way’ to non-Japanese factories.