Thanks to agile executive, I realize that golf and agile really are much alike.

Ben Griffiths seems to know how to pull the right strings to get Rubyists drool sporadically:

Simon asks, How do you map requirements to code and presents an idea he had recently, basically tagging certain points in your code with an annotation identifying the requirement related to that specific action.

So, how do I map requirements to code? I don't. I really don't. Explicitly. But if I did, I'd probably tag my acceptance tests instead of the production code because I'm more interested about the reality itself rather than the difference between the reality (observed coverage of a given acceptance test) and my intent (annotation on production code).

I am of the opinion that simply having a suite of acceptance tests written in the domain's language is enough for mapping requirements to tests, and from there we can more or less let the computer figure out which parts of our system are involved in implementing a given feature or an aspect of it.

I don't know if my take on this is any more right or wrong, better or worse than anyone else's. Not to mention that I haven't spent much cycles on thinking about the whole thing in the first place. I would also be interested in finding new perspectives to look at requirements traceability from.

I recently found the following blog entry through my referral logs. It collects some very useful links to various presentation styles into a single place. Nice. Thanks.

The Good, Bad, and Ugly of PowerPoint

I'm personally very fond of extensive usage of pictures instead of bullet points. The less text on a slide, the better. Knobs turned to 11 (or perhaps "-1" would be more appropriate in this context). In fact, here's a couple of thumbnails from the slideshow I'm going to present next week in a Merito Forum seminar on testing.

Isn't it interesting how sometimes you can just tell that a given team or community is jelling?

Reading the above blog entry from project.ioni.st got me thinking why is it that we typically (and I might be over-generalizing a bit here) bond through playful name-calling and other similar acts. And yes, it's predominantly a male thing.

The name-calling thing is harmless and seems to be a rather effective means of bonding as long as everyone involved has an understanding of the rules of the game. For example, saying "oh my god, I haven't seen crappier code than what you just checked in in ages!" is probably not going to fly with any software developer alive while accusing the same software developer of having an abnormal preference for beep-beep-beep beep beep-be-beep beep is quite ok. The farther the topic is from the actual work being done, the easier it is to recognize the name-calling from real opinions.

Obviously visual clues have a lot to do with it. I would seriously recommend avoiding such a name-calling pattern when dealing with a multi-site scenario where the name-calling happens over a wire and not face-to-face. The smile saying "you couldn't have come up with anything smarter than the line I just threw at you" that accompanies the witty insult is pretty crucial...

Anyway, yes, the bent-over-backwards approach to bonding that is this name-calling game does indeed seem to work. Teams that develop this kind of behavior are often those that seem to possess ownership of what they do and hold common goals. Yet, I can't help but thinking that the reverse psychology part of it is muda, waste.

Keeping my amateur psychologist hat on a while longer, I suspect that the reason we aren't too keen on bonding in a more direct way is because of personal safety. We want to feel safe. It's the hierarchy of needs thing, remember? For some reason, we tend to feel less secure revealing our true emotions and true feelings than we feel about giving hints along those lines, while still retaining a chance to take our words back.

We all know how good it feels when someone you think highly of says something nice about your work. Imagine if even a small part of that playful nagging and name-calling would be replaced by direct communication about the good work you or another team member has done.