Coding Dojo @DR 001

Below you'll find all details of the first Coding Dojo @DR meeting. Please comment on this post with your opinion or concern on any topic. If you haven't read this post, please read it to gain a better understanding about this event.

I  -Event URL:  Kodisto Dojo @Google+

II -Katas Pool

We must select (see point 5 of Agenda), one or more Katas to practice on each Dojo session. The following list is an extract of some easy Katas, please review each one to be informed when making your decision. You'll find more Katas at this blog Code Kata's Page.

• Repeat Separator
• KataWordWrap
• Number Persistence[Multiplicative]
• Test data
• Kata Diphthong and Hiatus

III-Expected attendees: 21

IV -Expected duration: 3:25 hrs. (3 hours and 25 minutes)

V  -Agenda

1. Decide on date for next session: 5 minutes
2. Decide on a Topic for next session: Just TDD (0 minutes)
3. Coding Dojo and TDD introduction: 20 minutes
4. Code! PreparedKata by Rafael George (String Calculator): 30 minutes
5. Pick a / some Kata(s) for this session: 10 minutes
6. Code! RandoriKata: 40 minutes
7. Mid-session break to discuss how things are going: 10 minutes
8. Code some more: 70 minutes
9. Retrospective. What went well? What was interesting? What was frustrating?: 20 minutes

---

This section will be filled after the event.

VI  -Next event URL: http://goo.gl/vQ5Xk

VII -Next event date: Thu Oct 18 2012

VIII-Actual attendees: 11 (from 22 confirmed; No-Show 11)

IX  -Actual duration: 4:00

X   -Worked Katas:
Just String Calculator, see retrospective to know why.

XI  -Retrospective (If I forgot something, please comment to let the point registered)

What was frustrating?

• Use a moderator: Discussions took to long, and some of then were pointless. Also we try to talk all at the same time.  
• Respect the Prepared Kata format: We should be listening and looking at the techniques (TDD) presented with the prepared and respect the point of view of the person doing it. If someone does not understand a given step, the expositor must explain it; but that does not imply that both, the expositor and the attendee, must agree on the actual decision. The requirement is "not to move forward if someone does not understand the last step".
• Respect the Agenda: no one respected the agenda, we end-up by working just on one point of it.
• Respect the meeting schedule: only 4 (of 11 participants) arrived at the expected time.

What went well?

• Everyone stick to the usage of the technique (TDD) moving the focus away from resolving the actual programming challenge. 
• We cover all Test Scenarios of the problem.
• We add more Test Scenarios to the solution.

What was interesting?

• When is OK to stop the Refactoring step (of Red-Green-Refactor / RGR cycle)? or Is OK to do Early Refactoring?
• It's OK to put a little of "sugar" on the syntax of the produced code (by using more readable names or by encapsulating standard's API calls with private methods), in order to increase the legibility of the code?
• Those in favor defend the legibility to decrease the maintenance cost, and to increase the  code understanding.
• Those against say that the average developer must understand the code. And also that if we add too many methods we'll end-up with a large call-stack, making it harder when debugging.
• It's OK, or not, to do early optimizations?
• When to add more test scenarios? 
• Most attendees agreed that we must complete the original requirements first, and then add more scenarios to shield our code. 

Next meeting agreements:

1. Next meeting subject: TDD
2. Next meeting language: Java
3. Next meeting format: Randori
4. Place: <TBD>. Go to the Google's Event for more details.
5. Other programming languages options: C#, Ruby, and Python. Withing the attendees were at least one person with enough experience using each language.

XII -Action Points

1. Modify the next agenda to include an introduction to the Technique to be used (TDD, BDD, etc...)
2. Modify the next agenda to include an explanation of the type of meeting we'll have.
3. Include an early step to read the agenda to participants so everyone is on the same page and  respect it.
4. Upload the code of the Kata to a public location (github, bitbucket or similar), so everyone can review it.
5. Test the video recording software before starting with the Kata to ensure it's working as expected.