Experiences with the book club
Once a week, or anyway at periodical intervals, my whole team participates in a meeting to discuss a chapter of a technical book, or a rather long article, that has been previously read by all participants. By rotation, someone has to initiate the discussion and present the ideas of the chapter, getting feedback from the others on his understanding of it.
The discussion may last from 1 to 3 Pomodoros, and may contain not only theoretical aspects but also a code sample to talk about together, or an exercise at the whiteboard. There should be a mix of experts and beginners in the subject in the team for the club to work.
This book club institution is not a new idea: here's our experience with it at Onebip.
We started with a small experiment. For our first book club meeting, we chose an article on Bounded Contexts by Alberto Brandolini; it went well, as at the end of the Pomodoro everybody was contributing to the whiteboard exercise (identifying bounded contexts and their relationship) by providing knowledge on our different projects.
So after the positive experience, we went on and chose a full book: Growing Object-Oriented Software, Guided by tests. Much of the team was lacking experience with Acceptance Test-Driven Development and the design knowledge required to pull off this approach. Since developers are the best assets of a team (you can buy hardware and software off-the-shelf, but not them) this training tried to improve the skills of existing members instead of hiring casually. We still hire, but it's harder to find capable developers.
Fast forward some months and the Onebip team has welcomed the material: the level of design discussion has raised from lines of code and scripts to objects and responsibilities. Instead of explaining design and testing patterns one-on-one on the job, the more experienced members can now refer back to the book club episodes when giving advice. No miracles happen during a meeting, but having a common terminology and stated direction in design is worth the try.
We have finished the theoretical part of GOOS and are now implementing a new, low-priority feature as suggested by Mirko during our next meetings. We plan to rotate the keyboard between meetings to get everyone to make design decisions, while transferring a methodology to our colleagues: acceptance test-driven development with the extraction of objects based on the assignment of responsibilities, and the removal of duplication (see the rules of simple design).
Tips on the implementation
The book chapter has to be chosen in advance and copies of the book have to be provided to all members. This is easy with technical articles hosted online, as the office can be used for printing them; physical or e-book copies of technical books have to be provided instead (this, along with the time for meetings, is a small investment with respect to the potential of what can be learned: design and workflow skills.)
It's important to reserve a room in the office and to be strict on timing: we use Pomodoros to ensure that if one hour has been allocated, we don't keep colleagues busy for more.
You also has to make sure that anyone talks and gives feedback on what he has read, even if it's to call bullshit on the fact that tests are always written first (from his point of view; from mine is an assumption).
The company is already allocating paid time for the meetings, so in my opinion professionals should not read the book during the workday but on their own time. Improving yourself is something you should do anyway due to ethics...
How to stimulate and involve all of the team, that is the question. We have to make sure questions and interruptions by all the members are always welcome, especially during practical exercises. After all, in these sessions the goal is to learn, and the code written just a by-product: it could be thrown away at the end of the day with almost no loss.
However, producing something that goes in production helps grounding the fact that TDD and object-oriented design is the way we want to always work; it's also a real domain (payments and subscriptions for us) with real issues and non-functional requirements. Production code provides a sense of purpose and reality to what we are designing: the Roman numbers and prime factors katas are good for introducing TDD to new people, but their first question usually is: how do I write tests in our X thousands lines of code application relying on two databases and external services? We want to make the point that what we talk together is not a theoretical process that has to be toned down in ordinary work.
The book club is a way to invest time and a little bit of money (books, paper) in improving your team's skills; it requires only a few experienced members willing to drive the discussion and provide tips for the others. Use the allocated time wisely, but remember it's an investment on people and not a way to produce something, even when writing production code.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)