[LRUG] The codes

Brent Snook brent at fuglylogic.com
Thu Sep 10 16:14:03 PDT 2009

2009/9/10 Jordi Noguera Leon <jordinoguera83 at gmail.com>:
> Yes, changing the direction seams difficult, maybe there you have to be a
> dictator hehehe. But that's why we should've had a plan from the beginning.

If you go the purist TDD route then the design should just evolve. I
think the prompts to refactor coming out of the kata tool would have
been a good point to take suggestions for design. I think a few people
mentioned a rule about people only being able to make design
suggestions when the tests are green; seems like a good idea. Maybe
there needs to be a little more set practice around refactoring - if I
remember correctly we took it as just a suggestion and moved on.  It
might have been better to set some rules around that being the time to
stop and take suggestions on design.

The more I think about it, the more I realise that we may have also
not spent enough time at the start talking about our understanding of
what the current code did and how we would approach the changes.

> Can any pirate answer these two questions:
> Why we didn't define a MineSweeper class?
> Hadn't it been easier to solve the problem defining it?

I don't feel that the key is in using a class in the design. It might
have made the responsibilities a little clearer but I don't think it
would have made a hug difference in terms of how we progressed.

> Maybe the best think would be to have a spokesman (?) between the crowd and
> the pair. But definitely, I'm convinced that no-one should develop until
> there's a clear path...

I'm not sure if an intermediate person between the rest of the team
and the pair would make things any better; the team and the pair
really need to be able to communicate on their own. A clearly defined
moderator though could prevent things from going off the Rails (ha ha)
so much.

If you jump back to the martial arts metaphor, a moderator would be
like a sensei telling you "if you keep hitting the board that way,
you're going to break your hand". They'd work best as someone
completely removed from the team, just observing what is going on and
gently nudging everyone back on course.



More information about the Chat mailing list