Rob Smyth

Thursday, 28 February 2008

Team Build Box Pass Rate Metrics

In software development metrics are always 'interpretable' and prone to what I refer to as (pardon me but I cannot term it better) 'technical masturbation'. An interesting metric at work has been build box % pass rate. I'm not sure what it tells us. Each team's culture is different on how to treat the build box. One team has a 30% pass rate while another has a pass rate around 80%. One uses CI and the other does not. So what does it tell us?

Members in a CI team may find it useful, and acceptable, to "lean on the build box" by not running all tests prior to committing. This can be productive if the tests take longer than 5% of the commit rate and the build box breakages are fixed quickly (is 'quickly' relative to commit rate?). Are the gains can be greater than the cost? Does % pass rate metric reflect productivity. By 'productivity' I mean minimising time to profitable delivery.

Other teams may consider the build box pristine and not to be broken ever.

It occurs to me that perhaps the real issue is the time broken. In companies I've worked if the build took a long time (e.g. hours). So the consequence of a build break was higher and hence the team usually aspired to a no breakages policy. If you have such a slow build, faire enough. But a build time of hours is really a smell of tight coupling, I would eliminate the problem of long build time first.

So, I wonder if a useful metric coming out of this is the % time the build box is broken rather than the build box pass rate against commits?

Related links:

Adoption of Agile Methods Survey

Interesting survey on community adoption/awareness of agile methods arrived in my mail tonight here. The number of participants is not that large so I'm unsure how to read it. But scroll down to the bottom of the page for other surveys.

Wednesday, 27 February 2008


NDependencyInjection is a new, very promising, IoC / dependency inject framework. The team I'm on is shifting from Ninject to NDependencyInjection. The most useful feature already is resolving circular constructor references. Love it and I know it is under active development. Expect great things.

Tuesday, 26 February 2008


Language is such an important thing in software development. Patterns are a the classic example, they provide a vocabulary to communicate concepts like 'it is like a state pattern would be useful'. Likewise we have adopted a vocabulary for agile style development. Like TDD, red-green-refactor, refactoring, and now (hopefully) 'prefactoring'. It is term, invented by Nigel, that has become common in our team (Varian Australia).

The first time it 'jelled' with me was when taking a class that was ... well ... hmm ... 'legacy' code. It was full of 'if' statements making the intent of the class difficult to see. We wanted to add a simple corner case to the functionality. Nigel suggested to prefactor the code so that it would become self evident where to make the change. He meant refactoring done prior to change as opposed to the RED-GREEN-REFACTOR it was added a PREFACTOR initial step. The feature seemed to simple I thought 'na ... I can find were to insert this little bit of code with the time to refactor/prefactor it'. But half a day later the code was still bucket of worms.

So, "delete plan A and insert plan B" we did then try Nigel's idea of prefactoring. Prefactoring means refactoring the code prior to making the change so that the code's purpose is self evident. Or, in other words, where to insert the change is self evident (I will avoid a discussion of open-close principle for the moment). So when I said 'we did then try' I was using the royal 'we'. In other words off Nigel went prefactoring/refactoring the code. After just 3 hours the code became clear like a ship emerging from a fog and the change needed was just easy.

So, if you are confronted with unintelligible code to maintain, prefactor. It saves time.

Should we now say PREFACTOR-RED-GREEN-REFACTOR. Na, that just means you did not refactor last time.

Go Nigel!

Sunday, 24 February 2008

Mental Firewalls & Borg Group Think

While browsing some humour I came across a Flickr image with the title "Borg Warning". It had the following description:
While well-behaved group minds no doubt are selective of who joins (it is after all rather intimate) and unlikely to assimilate everybody nearby, there might be applications or situations where mental firewalls are down and brains easily form group intellects. Maybe the people in the icon should all be raising their hands in the same way, but this is the clipart I found. "
While written as humour about borg-like group think, I find it insightful into group/team behaviour. Particularly the reference to intimacy and the term "metal firewall".

Just for fun, more on these "Warning Signs For Tomorrow" signs here.

Saturday, 23 February 2008

Threaded Applications Do Become Unstiched

A design defect that I keep coming across is the overuse of threads in applications. The worst case as several years ago when I came across code that used threads as a type of queue. That application crashed when the number threads got to a few thousand threads. More recently an application became much faster and more stable when the design was changed to remove all threads.

Using threads causes:
  • Application speed problems due to inherent delays in inter-thread communications and the inherent wait/sleeps that will creep in.
  • Require thread safe objects.
  • Leads to complex design which will lower code health.
  • Not deterministic.
The alternative is to make all slow calls asynchronous. No sleeps, no loops waiting for events. For timing use a timer in the same thread. The Windows UI thread is okay as you are never going to wait. Use call backs (e.g. delegates). Always do what is required when required.

When the design is changed to remove the threads the design becomes simpler (and hence the code healthier). Of course the change is done to eliminate intermittent defects (product health) which do disappear when the threads are removed.

Threads are added to code either because:
  • The future impact on the code health (the cost of that design) is not understood.
  • The alternative design approach is not known.
  • There is a fear of processing time to do what is required. You have no choice anyway as you must do what is required as "it is required" :-). If you use a thread it will just take longer anyway.
But, threads are not totally avoidable as our applications must interact with third party APIs. Only use threads to call to slow third party API synchronous methods. e.g. OS file call 'Open'.

If you have threads in your application, get rid of them. You are probably already having to update code to make it thread safe. If so, you just adding complexity as a design defect deodorant. The increased complexity will lead to more defects ... sound familiar?

Friday, 22 February 2008

Continuous Integration - More Build Lights

One of the great things we have done at work in recent months has been to raise build box state visibility by both sound (CruiseControl tray) and light (see my prior blog). The light has proved to be very effective.

I found some more interesting photos of what others are doing:

Thursday, 21 February 2008

eXtreme Programming War Rooms

I came across this site with many great photos of XP team war rooms and their charts. Interesting to see how other teams work spaces look like, how they organise their story boards, and the build box lights they use. One even has a set of traffic lights on the wall.

Check it our here:Room and Chart Gallery.

While I'm on it, some other big visible chart sites I would like to remember:

Tuesday, 19 February 2008

A Lovelly Farewell To Edith Miller

Yesterday I was in Perth to attend the funeral of my mother's best friend of 40 years; Edith Miller. I hadn't seen Edith for some years but she was a lady of such presence, and I often heard so much from my mother, that she just felt to me as part of our family. Strange how you see some people so rarely but they they feel part of your grain. It was a lovely funeral with a real sense of humanity. First time I've felt a positive feeling from a funeral. Glad I was there.

Robin: Sorry for not visiting while I was in Perth. It just did not fit. See ya next time though!

NXmlSerializer Rev 2.0 Beta Released

I've today posted a Rev 2.0 release on the sourceforge project site. Much improved code but more importantly new features:
  • Private field value serialization
  • Parameterised constructor support (does not require default constructor)
  • 'Just in time' type discovery
  • Simplified API

Sunday, 10 February 2008

NXmlSerializer updated

I've finally completed refactoring the NXmlSerializer code. It could almost be said to be a 'rewrite'. I now feel happy with the code. It now also, optionally, serializes classes by private fields. The idea is serialize the class's internal state rather than by public properties.

I know the code is in use in a couple of commercial projects successfully but it is still beta. I'm yet to update the SourceForge project documentation. Get latest on the source code, I will update the release binaries when I've updated the documentation. See how to use it my looking at the tests.

Known limitations:
  • Does not serialize read only public properties with an object type.
  • Cannot handle classes with read only fields.
  • Field reading does not, yet, support XmlIgnore attribute.
  • Cannot serialize classes that do not have a default constructor.
  • Still needs upfront discovery of domain types. Yet to add a more intelligent to discover 'just in time'. This will probably not be done until we see a speed issue.
The motivation for this project. That is "what it can offer", can be found in the old documentation here.

Saturday, 2 February 2008

A Pattern For Task Focus

Newcomers to an XP style of development, and especially completer finishers, often have trouble breaking down tasks. It is a much underrated skill.

The warning flag is the discussion mentions classes outside of the class being worked on, or, in other words 'the big picture' keeps looming up to hide the work.

So here is a behaviour pattern I'm working on:
  1. State the story in multiple single sentences. These are the use cases that will be used to the automated user acceptance tests (UATs).
  2. Now break the story in developer tasks, each a simple sentence of the form: "When ..... (set/tell) .... to .....". Smaller the better, do not be shy to have many.
  3. Implement each task.
  4. Run the UATs ... gosh it works!
Understand the customer requirements, break them down to short stories (a real kill), then divide it up into developer (not customer tasks). It is another view of ask not what you need to do to the code but what the code needs of you. When you are at task level the task tells you the unit test and from then on the code tells you what it needs.

The anti-patterns here are hearing talk of 'how to do it' rather than what is needed. For example 'inject object X into Y'. This stuff is how, but does not add functionality. Make the code tell you to do this.