Lessons Learned from Mob Programming

Recently, I had enough time to experiment with mob programming, a revolutionary technique for developing software. It's like pair programming with 6-7 team members in stead of 2! Seems ridiculous, right? This is how extreme programming (XP) practices seam at first before they spread like wildfire!

For those who didn't hear about it, please watch this video:

To get a deeper dive, watch this lecture by Woody Zuill, the father of the idea.

Currently, mob programming is spreading so fast in the world, and people are starting to realize so much value out of it. In the Agile Conference 2017 (which I'm on the reviewers list of its program), we have two sessions on mob programming, one talks about this technique used for on-boarding large number of people, and the other talks about it in teaching colledge students.

Working With Mob Programming Onsite

Now, back to the topic. I worked with two teams to whom I introduced and used this technique. One of them in co-located, and the other is distributed. I'll introduce the setup of the onsite experiment, then will list some observations and lessons learned from both teams.

We have restructured the room, got a projector, and started the session. Here is what we've done:

1. We have dedicated an on-wall kanban board, other than the one on Jira
2. Started with three main tasks for the day, which are the most important ones so far
3. I have explained some basic rules for the game, one of which is that I'll act as the facilitator
4. Then we started!

Rules of the game

Several basic rules are put into action:

1. We'll break every now and then, probably once every 1-2 hours
2. It's ok that you leave the room for any side task, not for so long though
3. Any emerging unplanned task will be put on the backlog. We've started with three tasks on board, and ended up with about 13!
4. Work is time-boxed from 10 am till 4 pm. No other "significant" work should take place outside these working hours

How people felt about it:

"Some tasks would have never been carried-out without mob-programming them" - one team member

 It's very interesting seeing how people interact and collaborate during the session. Here are some observations I noted:

• Contrary to what I expected, technical leaders and development managers where happier with this technique. They felt more confident and more productive. Plus, they appreciated learning from other team members while mobbing!
• Learning took place in all directions. seniors taught juniors and vice versa. Old team members taught new one and vice versa. This was amazing! One can never think of what new ideas, techniques, even inspirations he'll learn from other team members unless he start working with them hand-in-hand
• Interaction and collaboration were high, definitely higher than solo-programming, probably a bit lower than pair-programming. Again, this is contrary to my expectation, which was that half of the team will take a long nap during the session :)

 Finally, here are some feedback points I got in the retrospective;

• It was fun! and joyful
• Some tasks would have never been carried-out without mob-programming them
• We used to do the same task so many times. This way, we all do it one time!
• Collaboration with the product owner is much better; we all ask him the same question, get the same answer, all at the same time
• It's a better approach to reach the best solution for a problem
• It's less suitable for small and easy tasks
• It may be impossible to work this way if we're working under pressure

All-in-all, it was an excellent experience. Right now, I'm engaged with a company doing remote mobbing as a means to train new team members in a faster and more effective way. Guess what? Still the old team members learn from new ones!

Integrating Jenkins and ConQAT to Enable Continuous Clone Detection

One of the great features of ConQAT is its ability to detect code clones (duplicates). On the other hand, CI servers like Jenkins enables you to automatically check for code quality attributes. If we can merge both, this will become an invaluable tool for technical team leaders and will save them a lot of review effort.

Here is how you can do this:

Step 1: Define Your Policy of Preventing Code Clones

This is done by specifying the ConQat Run configuration files (.cqr) using eclipse. That is, create a cqr file which detects kinds of duplicates that you don't want to see in the code altogether.

For example, you may define a cqr file which detects exact code clones of length greater than 10 lines of code. This is a screen shot of a cqr file which does exactly this job:

ConQat Run conf file with parameters

Step 2: Invoke ConQAT cqr from Jenkins

Ant can do this using shell scripts or command lines, as follows:

cd  <ConQat Location>\conqat\binconqat -f <cqr file location>\JavaCloneAnalysis.cqr

 Note: Make sure that you specify the output directory in the configuration file appropriately, because Jenkins will be accessing it later in the next step

Step3: Introspect the clones.xml file, and fail the build if it has clones

Let Ant check the clones.xml file generated. This is an ant target that does this job, add it to your build.xml file:

<!--=========================================================================

Check the file named in the property file.to.check (the clons.xml file) to see

if there are any clones.

The way this works is to find all lines containing the text "cloneClass" and put them into a separate file.  Then it checks to see if this file has non-zero length. If so, then there are errors, and it sets the property clones.found. Then it calls the fail-if-clones-found target, which doesn't execute if the clones.found property isn't set.

-->

<target name="check-clones-file"

        description="Checks the file (specified in ${file.to.check}) for clones">

       <property name="file.to.check" description="The file to hold the clones" />

       <copy file="${file.to.check}" tofile="${file.clonecount}">

              <filterchain>

                     <linecontains>

                           <contains value="cloneClass" />

                     </linecontains>

              </filterchain>

       </copy>

       <condition property="clones.found" value="true">

              <length file="${file.clonecount}" when="gt" length="0" />

       </condition>

       <antcall target="fail-if-clones-found" />

</target>

<!-- Fail the build if clones detected-->

<target name="fail-if-clones-found" if="clones.found">

       <echo message="Code clones found - setting build fail flag..." />

       <fail message="Code clones detected during ${codeline} build.  Check logs." />

</target>

<!-- ================================================================== -->

Note: In order to pass parameters to the ant script, click on the advanced button and add parameters as in the following screen:

Passing parameters to Ant