I thought I would share my new preferred tool: sonar.

It is a web application that enables to visualize and exploit the results of static analysis tools, tests and dependency analysis tools. It gives a fantastic view of the overall quality of your code, highlights the problem areas and even enable you to visualize the highest priority items.

My favorite piece is the technical debt optional plugin. With some effort you can probably make it somewhat accurate for your particular circumstances. Which would be somewhat missing the point. Ideally you would want to use it as a benchmark value across organizations as the appetite for quality is already reflected in the rules you choose to include in the analysis.

And did I mention it is effortlessly populated from maven ?

I wrote a long time ago about how I would like these two tools to be combined.

In the end I gave it a shot and just posted that on github. I have not tried it in real life yet but I will soon. The README explains the intent and the design assumptions. Check the tests for some examples.

On the other end, nothing is more than valuable than your input so please let me know what you think about it.

This article is the second in the series started with the use of cost.

In agile software development the cost of a story has this interesting property that it is highly correlated to the time it takes to implement it. Consciously or unconsciously cost is used as a proxy variable for time. Actual implementation times in turn tend to be hijacked by managers to measure performance by comparing them to cost estimate. Points are often used to remove that parasitising.

While using points is good, what we really need, the purpose of estimating cost in the first place, is the ability to layout project plans in terms of time. In comes velocity that enables the transformation back from points into time. I have witnessed enough attempts to manipulate the velocity either to look good when reporting in or to transform it into a measure of productivity (including at the individual level) to have entirely lost faith in its usefulness. Burn up charts are a lot more useful. They illustrate trends rather than instant pictures, they keep people at the project level rather than the individual contributor and they provide a view of the evolution of scope.

Finally let us focus on the estimation process. I firmly believe that this process is very important as it is unveiling the real work that will be needed to complete a story. It is a crucial analysis and design process. It is very unfortunate that the cost, the number, that comes out of the process considerably overshadows the other outcome: the establishment of common knowledge in the team. It is the learning that happened that is in practice the all important outcome. This learning is sometimes expressed in artifacts, from new stories being created, to new examples being attached to the story, to a change in the definition of done. All of which are rich expressions. Cost in contrast is the poorest of them all. Why then try to estimate it or even make the focus of the process?

Estimating should not be the focus of the analysis process. The focus of the analysis process should be to ensure the stories are ready to be implemented. In other words make them of a tractable size with an agreed upon definition of done. Tractable size means they all have more or less the same cost. The cost of the story becomes a measurable random variable that provides some indication on the predictability of the process. The distribution probability of that variable can be influenced by changing the process. And in return the effect of process changes can be measured usefully. It provides management with a tool to forecast the future and to influence it. It removes the cat and mouse game that estimate versus actuals tend to become. It helps measure the performance of the project rather than that of individuals. And last but not least it focuses project teams on risk adjusted value rather than cost to prioritise their work.

That is what we have been experimenting with for the last 10 months. Although we do not actually measure the monetary cost of a story but rather its lead time. It is the cost in terms of time, an acceptable approximation considering the previous argument that the bulk of cost is personnel. So far (excluding vacation induced outliers) we average 6.23 calendar days per story from analysis start to close with a standard deviation of 3.82. Our targets for those numbers are 8 and 2.5 respectively meaning we would trade a higher average for less fluctuation. The probability distribution derived from this data also enables us to make useful predictions about the possible lateness of a story, when the lead time breaks the 3 sigma barrier, and to react to it earlier. For instance a story that reaches 8 days of lead time has 28% lateness.

Here is a unit test that illustrates the Fly Weight implementation of Integers in Java.

import junit.framework.TestCase;

public final class TestIntegers extends TestCase {
    public void testValueOfGivesTheSameIntegerForSmallValues() {
        assertSame(Integer.valueOf(1), Integer.valueOf(1));
    }

    public void testValueOfGivesADifferentIntegerForSomeValues() {
        assertNotSame(Integer.valueOf(13333333), Integer.valueOf(13333333));
        assertEquals(Integer.valueOf(13333333), Integer.valueOf(13333333));
    }

    public void testNew() {
        assertNotSame(new Integer(1), new Integer(1));
        assertEquals(new Integer(1), new Integer(1));
    }

    public void testValueOfGivesTheSameIntegerForAutoBoxing() {
        assertSame((Integer) 1, (Integer) 1);
    }

    public void testValueOfGivesADifferentIntegerForAutoBoxing() {
        assertNotSame((Integer) 13333333, (Integer) 13333333);
        assertEquals((Integer) 13333333, (Integer) 13333333);
    }
}

Here is why you should use compareTo to find out whether two BigDecimals represent the same number or not.

import java.math.BigDecimal;

import junit.framework.TestCase;

public final class TestBigDecimal extends TestCase {
    public void testBigDecimalZeroEqualsBigDecimalValueOfZero() {
        assertTrue(BigDecimal.ZERO.equals(BigDecimal.valueOf(0)));
    }

    public void testBigDecimalZeroNotEqualsBigDecimalValueOfZeroDot() {
        assertFalse(BigDecimal.ZERO.equals(BigDecimal.valueOf(0.)));
    }

    public void testBigDecimalZeroEqualsBigDecimalValueOfZeroString() {
        assertTrue(BigDecimal.ZERO.equals(new BigDecimal("0")));
    }

    public void testBigDecimalZeroEqualsBigDecimalValueOfZeroDotString() {
        assertTrue(BigDecimal.ZERO.equals(new BigDecimal("0.")));
    }

    public void testBigDecimalZeroNotEqualsBigDecimalValueOfZeroDotZeroString() {
        assertFalse(BigDecimal.ZERO.equals(new BigDecimal("0.0")));
    }

    public void testBigDecimalZeroComparesToBigDecimalValueOfZeroDotAsZero() {
        assertEquals(0, BigDecimal.ZERO.compareTo(BigDecimal.valueOf(0.)));
    }

    public void testBigDecimalZeroComparesToBigDecimalValueOfZeroDotZeroStringAsZero() {
        assertEquals(0, BigDecimal.ZERO.compareTo(new BigDecimal("0.0")));
    }
}

I used to like overloading methods to provide a default behaviour for any object and a specialised one for some select types. That’s possible when the language supports multiple dispatch. It is not possible in Java:

import junit.framework.TestCase;

public class TestOverloading extends TestCase {
    public static final class OverloadedClass {
        public String thisIsA(final Object o) {
            return "Object";
        }

        public String thisIsA(final String s) {
            return "String";
        }
    }

    public void testIsCallingObjectFromObject() {
        final OverloadedClass tested = new OverloadedClass();
        final Object value = new Object();

        assertEquals("Object", tested.thisIsA(value));
    }

    public void testIsCallingObjectFromString() {
        final OverloadedClass tested = new OverloadedClass();
        final Object value = new String();

        assertEquals("Object", tested.thisIsA(value));
    }

    public void testIsCallingStringFromString() {
        final OverloadedClass tested = new OverloadedClass();
        final String value = new String();

        assertEquals("String", tested.thisIsA(value));
    }
}

Last tuesday’s meeting at the BayAPLN was a talk by Jim Highsmith entitled ‘Beyond Scope’. The talk itself was very interesting and did trigger some thoughts that I will try to organise in four or five posts. This first one is about cost.

How is cost estimated ?

There are numerous articles, methods and even books that describe how to do cost estimation for agile stories. In my limited world the consensus seem to be that cost estimation should be relative rather than absolute. It can be expressed with numbers or words. It also seems that one of the preferred methods for cost estimation is the planning poker. In that space more formal methods have been proved to work although they are rather tedious to practice.

Cost estimation for planning

Usually it is used to give an estimate of when the project will finish. As it happens, in software intensive systems, most of the operating expense is the payroll and so setting the length of the project is also essentially fixing its cost. And in many cases people will jump from one notion to the next. Now the trick is that to go from relative cost estimation to cost planning, some time equivalence has to be defined.

While we all know that circumstances (such as technical debt, absence of key team members and the colour of the sky) will make these equivalences vary over time, they are usually used in a normative way. In other words the team’s performance will be evaluated with regard to its ability to match the equivalent time that was initially chosen. In the worst cases it will be used to perform individual evaluation.

Cost as a proxy for value.

This however is a minor managerial effect. Use of cost estimation has a few implications of its own. First, while this is rarely expressed it means the scope is set. Otherwise, the planning is meaningless and what use do we have of the cost estimation ? I hear your answer: to give the business an idea of how to prioritise the stories. I was more than once on the losing side of arguing the business should prioritise before cost is known. In other words, cost is used as a proxy to value.

Is cost a good proxy for value ? Is something expensive a worst value than something cheap ? Or the contrary ? Worse, in a software system actual cost is usually dependent on the sequencing of stories. Or on how many stories a structural cost can be amortised.

To sum up.

Cost estimation is easy to come up with. It appears to be an easy control variable to measure the performance of the development process. It also appears to be an easy indicator to determine the priority of stories. In reality, is it good at any of that ?

Over the past few months I have grown to like the ‘given a’ syntax more and more (described here). So when I recently reactivated my Ruby On rails home project (see brikeyard deployed on heroku), I thought I would add that syntax to my rspec examples rather than use before(:each).

I have not spent too much time thinking about where to put this code. Nor did I spend much time peeling away the nested modules inside rspec. Ideas to make this better are very welcomed. I would also love to collect some feedback on this before I make a fool of myself by proposing its inclusion in rspec proper. Thanks in advance for your help !

Here is how the setup looks like in one of the specs:

describe :something do
    given {
      a StatisticalControl
      a WorkItem, {:lead_time => 1}
      another WorkItem, {:lead_time => 3}
      a ProcessStage, {:work_in_process => [a_work_item, another_work_item]}
      a ControlChart
      @project = Project.new
      @project.stub!(:lead_time_control).and_return(a_statistical_control)
      @project.stub!(:closed_stage).and_return(a_process_stage)
    }

    it "should do something useful" do
		(...)
    end
end

And here is what I added to my spec_helper.rb file:

def a(type, stubs ={})
  stub = mock_model(type, stubs)
  member_name = type.name.gsub(/[A-Z]/) {|match|
    "_#{match.downcase}"
  }
  instance_eval("
        @a#{member_name} = stub
          def a#{member_name}
            return @a#{member_name}
          end
      ")
end

def another(type, stubs ={})
  stub = mock_model(type, stubs)
  member_name = type.name.gsub(/[A-Z]/) {|match|
    "_#{match.downcase}"
  }
  instance_eval("
        @another#{member_name} = stub
          def another#{member_name}
            return @another#{member_name}
          end
      ")
end

class Spec::Rails::Example::FunctionalExampleGroup
  class << self
    def given &block
      before(:each, &block)
    end
  end
end

class Spec::Rails::Example::ModelExampleGroup
  class << self
    def given &block
      before(:each, &block)
    end
  end
end

Please let me know what you think. I welcome suggestions to improve.

In our process we have started using two metrics in addition to the cumulative flow diagram indicator. These metrics are tracked against target values to measure if the process is in statistical control.

The first metric is the lead time. It measures the time in days between the moment a work item enters our process and the moment it is declared finished and exists the process.

The second metric is the throughput period (the inverse of the throughput rate) which is the time in days between the end dates of successive work items. If we note two cards C1 and C2 with start dates SD1 and SD2 and end dates ED1 and ED2, then the lead time for C1 is (ED1 – SD1) in days and the cadence for that period is ED2 – ED1.

Over a period of time these measures can be plotted against a target mean (10 days of lead time and 4 days of throughput period) and a target deviation (5 days for the lead time and 2 days for the throughput period). These targets can be changed independently as our process matures. Improvement to the means benefit the delivery speed. Improvements to the deviation benefits the predictability.

Finally you will find here the model I use (for Apple’s Numbers) to visualize these process metrics.

Learning this lesson cost us two weeks of throughput. Here is what happened.

We started work on a feature that was dependent on external resources for completion. In anticipation of a quick completion (based on past experience with other providers), we filled our “Analysis Compete” queue with work that depended on the completion of the work in development.

Of course, completion was delayed and it involved a lot of waiting and very little work. So the bottleneck resource, me, was under utilized. As the delays dragged from day to day we tagged the work with an issue and thought of pushing some other work instead. But all the work in our stream was dependent on the resolution of the issue. I did not want to break WIP limits so we could not simply start a new work item. So I kept myself busy with some refactoring.

There are two bad things that stemmed from this. First we lost throughput. Second I did work that will not be verified as a story would have. The good thing to come out is that we reflected on how to improve.

The first improvement is obviously to limit dependencies between work items that are in process. In particular those for which we do not fully control the completion. The second improvement is to try to avoid saturating our queues, in other words avoid a one hundred percent utilization of them. The third improvement is that we are now comfortable dropping work in process when we find out that either it cannot be completed in a reasonable amount of time or it does not have the value we anticipated.

What do you think ? Are there other lessons that we should learn ? Do you have any advice on how to anticipate these issues ?