Friday, February 13, 2009

SmellyRoom

As a software developer I fight "Smells" as much as I can.

I love the term, it's very plastic, intuitive and easily adopted by most of the people. I use it with different meanings: design smells (code that screams for refactoring), software aging smells (deprecated, dead code), testability smells (untestable code, low code coverages), etc..

I first encountered the term in Refactoring - Improving the Design of Existing Code, and I adopted it instantly. When I use the word, I'm understood immediately!

One of these days, I had a discussion with a colleague of mine and we laughed together about a new meaning of the word, or if you wish a new metaphor, old software projects as Smelly Rooms:

As you stay longer in a smelly room, you adapt, you find the air there more breathable. You even start to think there's nothing smelly with the air you bread. Same can happen when living too long in a Smelly Project, you can get used to the design smells, software aging smells, etc. It's possible you'll even start to think you're working on a state of the art piece of software!

The cure for this disease in both cases, smelly rooms and smelly projects: the door. Use the door to see the hallway, to enter other rooms, you'll just know you need to open some windows. Enter doors towards external projects (read books and articles, discover tools, have a look on an open source project, attach sources to external libraries you use and explore them, etc), and you'll just know you need to perform some cleanup to your old project.

Wednesday, February 11, 2009

Group Reading Writing

During the past year I had the opportunity to experience Group Reading, to continually grow understanding on this agile practice and to contribute to practice’s adoption and refinement in a number of development teams.

Reaching the time of year that is most suited for personal retrospectives (or was, I started this post on December last year!), it is time for me to write down a number of ideas, teachings and best practices discovered by trying to set up and get most of value from this learning technique.

What is it?

Group Reading is an agile learning technique that can be applied by a group of participants by simultaneously reading the same piece of technical text and sharing the individual understandings obtained from that text. The participants should be work related, i.e. parts of a development team or development group and the text should be interesting enough for each team member.

What can I gain from it?

If they are set up correctly and if they are continually subject for improvement, the group reading sessions may provide many benefits for each individual participant and for the team as a whole.

Each person when reading a text has his/her own paths of interest, words that are more appealing, paragraphs that worth more concentration, different reading and learning techniques used voluntary or involuntary (SQ3R, literary reading), performs analogies with past experiences, etc. As a result, when many persons share their understandings obtained from the same text, each person may learn from the others. It is very likely that missed points for one person to be very interesting ideas for another. So, each participant may read more in group than by reading the same text alone.

Other individual benefit for each participant would be the effective learning of the read topics. By discussing ideas and associating them with concrete examples, by putting them into context) ideas may become well sedimented in memory.(Learning by teaching and more).

Appetite for self improvement can also be a result of this practice (Why wait such a long time to finish this reading in group? I can buy and finish the whole book in one or two weeks and I’ll also read more in group reading sessions!). By reading small chunks reading appetite can be awakened, the book used in the group reading may be a start, but other books may follow also.

For the whole group the main benefit of this activity is related to group’s cohesion: common vocabulary and interests for the team members, common goals regarding future development work, growing respect between team members are only some of the aspects.

Good teams are formed over time, partly because team members have individual educational backgrounds and vocabularies, partly because teams need social background and good interactions.

Group reading sessions may help shorten the time needed to create good teams: by constantly adding common words in a team’s vocabulary, shared ideas as new words, the team may gain good communication skills and common concerns; by taking the team members out from their regular work environment, they may forget their working roles and socialize, feel equal, discover that some questions may be answered by someone near, respect each other’s ideas, etc. Yes, group reading is also a form of team building!

Finally but not at the last group reading session may be a small artifact in building a good working environment, where people put passion on what their doing, where auto improvement is constantly demanded.

What is it not?

Group Reading is not following a presentation, is not a discussion on known topic is not watching a technical podcast in a group. Is a simple reading act followed by a discussion and nothing more than that. Keeping it’s sessions simple, finding good subjects, can lead to the benefits listed above. Less is more, twisting and tailoring practice’s scope may not lead to optimal results for the participants.

Group Reading vs. Peer Programming

Peer programming is another agile practice that can lead to rapid teaching and learning and may help forming good teams quicker. My guess is that in many agile teams peer programming is the only training practice in use in the development phase.

This is normal until a certain point. The most appropriate teaching material intended to improve our work as programmers is the code itself, it’s abstractions, external libraries, documentation, design, etc. Having an experienced team member nearby is the best place to look for experience and good practices. During peer programming sessions, knowledge and skills owned by experienced team members may be rapidly shared with the whole team. The only problem here is the degree of knowledge and experience of the experienced team members: maybe different, better knowledge artifacts are recorded in an existing famous book or article or other form of documentation.

So if Martin or Kent or Robert or "you name it" is not yet your peer, maybe his/her recorded ideas could be your partners in group reading sessions!

Organizing Group Reading Sessions


As with any agile practice, the key in organizing effective group reading session is practice adaptation to real context: Just see if it’s appropriate for the team you’re in, try it, see what can be done to get the most value from it!

Over time, for groups I was part of, we discovered a number of points that lead to better group reading results.

In terms of duration we discovered that 30 minutes sessions are enough. 30 minutes sliced in 15 minutes reading, 15 minutes open discussions seemed the optimal amount of time we could stay concentrated on a new topic. We also discovered that almost any reading material can be sliced in cohesive parts that can be read in 15 minutes: 2-3 pages parts.

In terms of planning we discovered that is better to plan a number of subject related group reading sessions. This way the sessions became parts of a larger goal. A goal that can be tracked and addressed iterativelly (see progress monitoring, bellow :) ). Planning also implies priority. By planning 1 session per week we ensured that the whole group recognizes the session as being high priority. We obtained this way a group acknowledged priority.

In terms of participants we discovered that most of the group reading benefits can be obtained in teams of 3-4 persons. Having more than 5 persons in a group reading session tends to increase the open discussion time: every person tries to say it’s view on the read topic, etc. We also discovered that the degree of experience of the participants doesn’t matter too much: experienced developers can learn from beginners, beginners from beginners, etc. In one team I worked for we even played a lottery game to extract group reading session’s participants!

In terms of progress monitoring we discovered that having the planned group readings and their dates on a flip chart, a marker and the possibility to mark them as done, is good for the morale!