In my career I had the luck to hold jobs where I could exchange useful feedback on coding practices with very smart people. I have also held jobs where that is not possible. Back in the not so distant days when I did not use continuous integration and unit tests and such goodies, I was left with learning from experience, painful as it can be. Nowadays however a lot of tools, kindly provided by a wide community, especially for the Java language enable rapid and specific feedback on your work. For the remainder of this post I will stay on the side that I know best with Java.

I have been using static analyzer such as checkstyle, PMD, Findbugs or JDepend for a few years to give me useful information on my code and left it at that. More recently I have used the violations reported by those tools (to which I added Sonar) and started to actively try to reduce the number of violations, focusing on specific ones. The one that yielded the biggest improvement was ‘design for extension’. The package circular dependency analysis also pushed to think more about how packages should be structured where interfaces should go and which classes should be available outside their package. It has been very satisfying to notice how much more liveable my code has become.

To be sure this would not have been possible without a good amount of automated tests and continuous integration and source control management to provide the necessary safety net for experimentation. Next I will work on staying out of the red (I have to admit I originally dismissed this idea when I saw it presented by Joshua Kerievsky) as I am starting to see how valuable it is to leverage modern IDE capabilities and structure the mental processes that underpins refactoring.

How do you do deliberate practice ? What are the tools you would recommend for it ?

This is a topic that came up in a vigorous conversation recently. The example we used was whether or not tests should be written for accessors. I was on the yes side and will expose my arguments here.

My first argument was yes because it has happened time and again to me that the wrong member was returned by the accessor. The counter argument was that code inspection would often reveal those issues.

My second argument was that the tests are not written only to validate the code at the time it is written but also for the future when changes happen. The counter argument being that in the mean time it is that much more code that needs to be maintained.

My final argument was that in any case it was simpler and cheaper to set as a policy that everything should be tested and then agree on exceptions during code reviews compared to debate for every piece of code whether it should be tested or not. That being said the policy might also be ‘test everything except accessors’.

I failed however to make the argument that I find the most useful: if is not worth testing, why is it worth writing ?

Your thoughts, arguments and counter arguments, as always, are very much welcomed.

I love this story by Alberto Savoia. Thanks to Mo for clueing me in on it.

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.

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.

I recently had a pressing need to return to one of my youth’s favourite pass time: the jigsaw puzzle. I, shamefully, never realised that this was related to the basics of problem solving. So here are my observations from the latest jigsaws I did.

You need a big picture to build a mental representation of the problem. This enables to make sense of the various pieces and enables to organise them in groups. The big picture also drives the resolution strategy such which elements to tackle first, the big groups and how they relate to each other.

You have a frame. That is a given constraint of the problem. It is usually useful to build the frame first but it is not necessary. The simple knowledge it exists is fundamental.

When I am assembling a puzzle I typically go trough iterative sorting, producing finer and finer sub groups with the pieces. This is enabled by the big picture and by the knowledge that is acquired over time of how the pieces relate to the big picture.

I proceed to the assembly in groups that are easily identified. I do not force the issue of finishing a group though. If a lot of pieces are missing, it is an opportunity to iterate on pieces sorting. If only a few pieces are missing, I will opportunistically gather them in a future sorting operation.

Sometimes I build small groups without knowing exactly how or where they fit in the big picture. Such groups are attached to other groups later on, after some more overall progress has been done.

Sometimes I misplace a piece. This usually happens in uniform parts of the puzzle, trying too hard to put pieces with little correlation from the neighbouring pieces. This leads to rework. It happened to me recently that I discovered the misplacement when trying to put the last piece. Resolution requires a careful inspection of how the other pieces fit together.

When a group is too difficult or proves elusive (such as a large area of a single colour), I alternate pointed and organised attempts at finishing it and pauses to resolve other parts. This usually means that they are the last parts finished. Usually at that point a spectator would be able to relate the puzzle and the big picture.

Although puzzles are significantly better structured and simpler than real life problem, I find that I apply a lot of the same strategies in my daily work. What do you think ?

This is a rebound from the openspace session I hosted at the BayAPLN event on April 21 2009.

III started by noting that it is not your money. I initially interpreted to mean that therefore we do not have to care. Except if you have been entrusted to manage it and you have a fiduciary duty to make the most of it. Which lead us to the two main themes that informed the question which we essentially held to be the two sources of technical debt. One was the managerial impact. The other is the professional integrity of the team.

Lack of planing, disregard for appropriate buffering on delivery dates, inability to motivate the development team are all very heavy contributors to the increase of technical debt. The primary reason is that they tend to strip the development team members of their professional integrity, part of which is the pride people put in a work well done. In essence those managerial attitudes are akin to asking team members to break the windows of the building they are making. Or to cut on the cost of material while building in a seismic zone. To that extend technical debt resembles more a ponzi scheme than an actual financial debt.

We found hope in the professional integrity of the team. This professional integrity means, in my mind, that a developer should leave the code in a better shape than he found it. Pushing further in that direction it means that repaying the technical debt is a deliberate opportunistic activity. In other words technical debt should not be repaid for the sake of it, but only when it causes friction in the current work. Its repayment becomes continuous and integrated in the work stream. However, a lack of professional integrity (whatever the reason) will let entropy creep into the system and burden it with technical debt.

The conclusion, for me is three folds. First I changed my definition of technical debt to “things that could be done better” (now not, not things we could have done better). Second, you should not have to care about technical debt. If you have to reserve time to address, something is broken and should be fixed first. Third some debt is good and even inevitable, don’t try to eliminate it for the sake of it.

I was reading Neal Ford’s excellent articles on the benefits of TDD, part 1 and part 2.

One thing that struck me however is the attempt to limit TDD to test first and how this lead to a somewhat dishonest presentation of the test after approach. In the first of these articles the test after approach is stopped before the refinement phase that is made explicit in the rest of the articles and is well worth reading.

It is unfortunate because the real benefits, in terms of quality, from TDD come from the feedback loop that is created between code and test. It is the iterative refinement of the test and the code that provides the real benefits. It is a chicken and egg thing. Neither comes first, what comes first is an initial design idea based on the problem statement. In Neal Ford’s articles, one of those design ideas is to extract the set of factors whereas the problem does not require it (it requires the sum of factors and in many cases only a partial sum).

Testing before or testing after is an axiomatic decision that provides its own set of benefits. First it emphasises that the developer has to think about the design separately from the code. To a large extend this opens creativity as the design will be less constrained by the existing code. It is an explicit permission to re-factor as needed. The second (maybe the biggest) benefit of testing first is, in my opinion, that it is a clear signal that tests are not considered as a second class deliverable but as a scaffolding and design tool.

So to summarise, TDD is a design method in which tests are a design tool (regression testing is a perk). Test first is a process element that helps initiate and sustain TDD.