May 1, 2009
· Filed under Point2 - Technical · Tagged collective code ownership, pair programming, scrum
During my current team’s daily Scrums we’ll finish up by organizing our day. It is usually pretty obvious what stories we need to be working on based on the state of the Scrum board, but who should be working on them is not always so clear. During the lifetime of a story (which most often is multiple days) I will start to get uncomfortable if it has been worked on by the same pair. As the Team Lead I’ll raise the question, “should we mix up the pairs?”
As a team we are striving to attain collective code ownership. We are close, but not quite there. In order to get there as fast as possible, I feel that switching pairs often is one of the answers, but in the early stages this can be difficult and exhausting.
The previous team I led did reach a level of collective code ownership. We committed to switching pairs at least twice a day, and facilitated this by introducing a mid-day stand-up to reorganize the team. We would also use this time to discuss the progress of our current stories, before getting back at it. Our experience at the time revealed the following pros and cons.
Cons
- lots of time spent “ramping up” a new pairing partner after joining a story in progress
- developers could become frustrated having to give detailed explanations to new pairs multiple times per day
- it was very draining for developers to have to switch contexts so often
Pros
- better design resulted from multiple developers being involved in the story
- developers were seeing all areas of the code
- the team was suppressing the creation of “experts” for certain areas of the system. Everyone was an expert – our truck number was rising.
- daily Scrums were becoming more useful since everyone understood the stories being discussed. No one had that glazed look on their face waiting for their “turn to report in”
- our velocity started to increase
The process was not easy, but as we pushed forward we found that the time to get brought up-to-speed gradually got shorter. During the daily Scrums our discussions were now leading the developers to form the pairs on their own in a more natural fashion. And before we knew it they were switching pairs outside of our daily Scrums whenever they felt it made sense. That’s when I realized we had collective code ownership.
Like I mentioned earlier my new team is still working towards collective code ownership so I am trying to implement some of the steps my previous team took. The team is larger, and we are working with a bigger and more diverse code base, but I am confident that we will reach our goal.
I am interested to hear about others people’s experiences in this area. What measures did your team make to maximize your truck number? When do you think it makes sense to switch pairs?
By Hemant J. Naidu
May 1, 2009
· Filed under Point2 - Technical · Tagged apple, Coding, java, mac, maven, mvn, netbeans, netbeans 6.5, osx, Programming, project, sudo, terminal
Since my last post, Defaulting To JDK 1.6 In NetBeans 6.5 On OSX, has enjoyed some popularity I decided to keep running with the NetBeans 6.5/OS X theme. NetBeans is a great, free IDE that supports more types of projects than the average developer would likely ever need. One of the most useful project types that NetBeans supports is Maven projects. If you are new to Maven, here is an intro to peak your interest.
For developers who have been using Maven for a while, you likely will be creating your projects (.pom files specifically) from a text editor but this can be a little overwhelming for those new to Maven or those who would rather simply spend their time writing code instead. NetBeans 6.5 makes it incredibly easy to create a Maven project in a matter of seconds.
First, go to the “File” menu and choose “New Project”.

Under “Categories”, choose “Maven” and in”Projects”, choose “Maven Project” and click “Next”.

The “Archetype” window should open next, select “Maven Quickstart Archetype” and click “Next”.

The “Name and Location” window will open allowing you to give specifics to your project. You can customize this as you see fit but for the purposes of this example I will leave the default settings. Click “Finish” and your project will start to build.

If you are running OS X 10.5.6, as I am, you will likely see the following error:
------------------------------------------------------------------------
[ERROR]BUILD ERROR
------------------------------------------------------------------------
Error resolving version for 'org.apache.maven.plugins:maven-archetype-plugin': Plugin requires Maven version 2.0.7
------------------------------------------------------------------------
For more information, run Maven with the -e switch
The reason for this is that OS X 10.5 shipped with Maven 2.0.6 pre-installed but Apple has never pushed any updates to it. According to the Apache archives, Maven 2.0.6 was released in April 2007 but it is kind of annoying that they didn’t realize that Maven projects would not work by default on OS X before they released NetBeans 6.5. Luckily, it is very easy to update Maven to the latest version if you don’t mind using the terminal and the sudo command.
- Download the zip with binaries for whichever Maven version you would like to install. At time of writing, the most recent version is 2.1.0, http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.1.0-bin.zip.
- Once the file is downloaded, you can extract the archive and you should end up with a directory named something like “apache-maven-2.1.0″. Open a Terminal window and
cd /usr/share
- Let’s move the current Maven directory to a backup folder in case we ever want to revert. In the terminal you opened in the last step, type
sudo mv maven maven-2.0.6. This will ask you for your password and then move the “maven” directory to a new directory called “maven-2.0.6″, assuming your user account has sufficient permissions.
- Now let’s put the new version in place so that NetBeans will start using it. To do so, we need to copy the directory we extracted from the zip file. Once again, in the Terminal window you have open, type
sudo cp -R /Users/dgabrielson/Desktop/apache-maven-2.1.0 maven. Keep in mind that the path to the extracted “apache-maven-2.1.0″ directory will have to be changed to the appropriate path on your system.
- Maven should now be upgraded! To confirm, in your Terminal window, type
mvn -version and you should see some output like Apache Maven 2.1.0 (r755702; 2009-03-18 13:10:27-0600).
Now if you try to build again, you should get a successful build log ending with:
------------------------------------------------------------------------
BUILD SUCCESSFUL
------------------------------------------------------------------------
Enjoy your new Maven build and get coding!
By: Damien Gabrielson