My team and I have made some startling observations about ourselves. Firstly, we are all approximately 5’11”, secondly most of us are musicians or hobbyists of some kind. Both similarities are completely coincidental, though maybe there is something more to the latter one.

One of my colleagues often says that when he’s recruiting, he looks for candidates with art or music backgrounds. His justification is that he feels they are smart and have a certain quality that makes it easy for them to pick things up quickly.

Somehow my department is filled with musicians. It’s not part of our screening process, however we’ve come to realize we have music in common. I think this has to do with the fact that when I recruit I look for the qualities that my fore mentioned colleague sees in most artists and musicians.

I play guitar and I know first hand how hard it is to be a good guitarist. There are certainly some people with natural talent, but I’m unfortunately not one of them. Being good takes practice, and lots of it. That’s a defining difference between musician-type and engineer-type programmers. An engineer-type tends to think that being good is a function of how intelligent she is. A musician-type realizes the critical role that practice plays in her path to perfection. Musicians also tend to understand how in the pursuit of perfection, improvements come in smaller and smaller increments however they are no less significant.

Musicians have some of the same internal struggles that engineers do. Take simplicity for example, when I first started soloing on guitar, I had a tendency to throw every note I could into a single line. I eventually learned how important the space in between the notes is, and how simple phrasing can be so much more interesting than a bunch of notes. As a young engineer I struggled with issues of simplicity and complexity for longer than I did as a musician. This could be related to mindset or maturity, either way I acquired an appreciation for simplicity in music much quicker than I did in programming.

At the 2010 Software Craftsmanship North America (SCNA) conference, my colleagues and I noticed a large number of musicians in attendance. It was somewhat of a theme, though not planned. The talk by Keavy McMinn was about her transition from artist to programmer, and Andy Maleh held a lightening talk on the similarities between playing drums and programming. And of course Chad Fowler mentioned his previous life as a saxophonist during his talk.

I really like the idea that musicians make good programmers. I had been thinking since I first started learning agile years ago, that I had previously been building applications that were far to rigid. That’s because I was building programs like you would build a bridge and I really needed to build them like you would a clay sculpture or the melody of a song.

So why do Musicians become programmers? I’ve seen and heard some reasoning around the mathematical nature of both music and programming as a potential cause. However, the theme from SCNA and my own experience seem to indicate that most of us are people who like to make things. Some of us start out with software, others start in music, art, construction or carpentry. All of these are just mediums to fulfill our desire to make new and interesting things. What makes software so appealing, at least for me is the extremely low barrier to entry. You just need to learn a language and have a computer with internet access and you can immediately get started making a computer do things it didn’t know how to do before. It doesn’t cost a lot of money and it doesn’t take a lot of space, it’s mainly a time investment. Software is a very forgiving and flexible medium that allows the people who love to make things to do what they love with the least amount of friction.

The project

I have some very simple release data that I would like to report on a weekly basis. The data includes the target release date, and the feature sets and feature set benefits that are targeted for delivery in the current release. Fortunately all of this information is stored in our project management and collaboration system as a result of our release and iteration planning procedure.

Mingle is a project management/collaboration system for agile projects. Since we do all of our planning in mingle, and since the development team uses the it to keep track of their work, it’s always up to date and it’s got all the information I need for this task.

I’m a little bit on the lazy side when it comes to procedure and I’m a firm believer that process and procedure is something that should exist in the background and help us do our jobs. Once you’re spending a lot of time managing your procedures, they cease to be helpful. Enter automation; I don’t want to be bothered with manually extracting information from mingle every week and emailing it. As it turns out, mingle is written in rails and it has a restful API. This makes it very easy to access mingle data via http. My task is made even easier by the fact that rails offers ActiveResource which maps RESTful resouces similarl to the way ActiveRecord maps database objects.

The Setup

We’re using mingle for our planning and team collaboration. We have cards in mingle for Bugs, Spikes, Stories, Iterations, Releases, Feature sets and Segments. We also have card trees for managing relationships between these card types.

Our release planning tree is used for bucketing stories into releases and later into iterations. This tree is constructed as:

    Release > Iteration > Story

Our feature planning tree is used for story writing and starts with very general segments (also referred to as theme’s), then breaks down into feature sets (or epics) and finally to stories, like so:

    Segment > Feature Set > Story

From the above trees it’s possible for stories from a single feature set to be developed in 2 separate iteration or even releases.

The Implementation

I was only able to find very limited documentation on the mingle api, and even less on using active resource with the mingle api. However i did come across this tutorial on using mingle with active resource which was a very close match for what i was trying to do.

The first thing I had to do was create the Card class which implements ActiveResource::Base and configures the site url.

require 'activeresource'
class Card > ActiveResource::Base
  self.site = "http://#{User}:#{Password}@#{host}/projects/#{Project}/"

  ...
end

Our release cards contain a start date and a projected end date, other than that they serve as a top level parent in the release planning tree. I also needed to pull the release date out of our release card. This part was pretty simple:

def Card.find_release(release_name)
  card = Card.find :first,
      :params => { :filters => ["[name][is][#{release_name}]"]}
  card.cp_end_date
end

Following that I need to pull all the feature sets for the current release and extract some description data. Since I know all the stories in a release, the ideal way to retrieve the feature set cards would’ve been to get the stories for the release and then back into the feature sets using the feature set card tree. This turns out to be more difficult than it sounds. Mingle uses 2 fields for identifying cards. There is the id, which is the underlying database index, and there is the number, which is the application level card number. Unfortunately some operations use id and some use number. Specifically, GET uses number and POST uses id. Card tree relationships are defined using id as the foreign key. What this means is that while it’s possible to get a card using its number, then post changes to it using it’s id, it’s not possible to look up a card based on a card tree relationship using foreign key which is an id.

The following will not work based on this id/number issue:

stories = Card.find :all, :params => { :view => "Current Release"}

feature_ids = stories.collect {|story| story.cp_feature_tree___feature_card_id}
feature_ids.uniq!

features = feature_ids.collect do |id|
  Card.find :params => { :filters => ["[id][is][#{id}]"]}
end

Fortunately I had another option. During our release planning process, before we pull stories into a release, we tag the feature set with a release tag (using mingle tags). We use this tag as a bookmark so that we can remember which feature sets should be delivered in the release while we are in the process of story writing and estimating. The mingle API for tags is pretty solid and easy to use.

features = Card.find :all,
    :params => { :tagged_with => release,
                 :filters     => ["[Type][is][Feature Set]"]}

features.each do |feature|
  email_body << "#{feature.name}nBenefit: #{feature.cp_benefit}nn"
end

Although the code ends up simpler, this solution isn’t ideal since previously tags were only an artifact of our planning process and also because the code is less expandable. I am certain that I will eventually want to report additional story level information and I don’t have a way to map feature sets to stories.

This was a very simple automation project. The mingle API is far more sophisticated than this project illustrates. The mingle API shows a lot of promise for integration into our build process.

Yes it’s true. Managers love metrics. Some managers may even attend clandestine weekend meetings to come up with more useless numbers to apply to the work that developers do. As we know from the days of LOC (Lines Of Code), these fail to capture the value or productivity of developers and sometimes mismotivate developers.

There is a lighter side of metrics though. They do have a critical place in software development, however it’s not for managers to measure their developers rather for developers to understand their code.

Even LOC has value, in fact it’s one of my favorite metrics. It’s now usually referred to NCSS (Non Commented Source Statements). This metric was once used to measure productivity as if more lines of code was a good thing. Ugh! Now we use NCSS to point out when we have too many lines of code. Imagine that, the managers had it backwards. NCSS is such a simple metric and yet it’s very powerful. It’s usually applied at the method level and is a clear indicator that you have large, complex and difficult to understand methods. Although there is no set number of lines per method that you should conform to, the general guideline is based on amount of time it takes to clearly understand a method. It should not take more than a couple of minutes to fully understand a method, and in my experience those methods rarely have more than 10 or so lines. Small methods that do one thing only and are appropriately named are easy to understand, so let NCSS help you find those methods that aren’t.

Another indicator of complexity is McCabe Cyclomatic Complexity (aka CCI or CCN). If you’re a masochistic feel free to check out the wikipedia definition, or you can just trust me and accept that it’s a good relative indicator of methods that have complex execution paths. For example, a method that has many return statements, nested conditionals and loops, and maybe even a few try/catch/throw statements for good measure. The greater the number of paths through your method, the higher your cyclomatic complexity. Since good unit testing would require you to cover all paths and CCI measures the number of paths in your method, CCI can also be an indicator of the number of tests you would likely need to get good coverage. Often you will see overlap between NCSS and CCI, just by the associative nature of size and complexity.

When using metrics to understand your code or to find deficiencies, be cautious to remember that these numbers are only indicators. It’s easy to see a nice number and think everything is OK. Not so. For example, another favorite metric of mine is code coverage. Code coverage tells you how many and which lines of code your unit tests are hitting and it’s usually expressed in percent of lines of code and percent of branches covered. I recall joining a project and running cobertura (a code coverage tool for java) to find out the project’s level of coverage. I was delightfully surprised by a relatively high number and so I went about my business of refactoring and changing code. When I eventually broke the code, I was surprised that it hadn’t been detected by the extensive test suite. After some inspection I realized that just because your test hits a line of code doesn’t mean that line is actually being tested. What I found were lots of tests with lots of System.out’s and very few assertions. The lesson here is to let your metrics point out problems, but if they tell you all is well check up on them. There is a saying in Journalism, “If your mother says she loves you, check it out.” This same skepticism should be applied when using code metrics.