Brio gauge seems to be the de facto standard for wooden toy railways. Pretty much all the cheaper makes of track fit (more or less) the Brio track and accommodate the Brio trains; the cheaper trains and carriages run on the same tracks, and even use the same (magnetic) coupling mechanism.

The Brio stuff is better quality and they have the lucrative Thomas franchise. I’d like to think that BRIO benefits from the cheaper compatible copies somehow expanding the market; I like the idea of free-market cooperation as well as competition.

More of those. Many months old now and hopefully safe to publish.

• This is how agile development works: first you need to gather all the requirements and write the functional specification; next you need to do the technical design; then you do all that iterative stuff.


• First we need the twelve month detailed plan. Then we can worry about the next two weeks.

I’ve decided not to continue this post on Cynefin. Better summaries of the framework are found here; there’s not much point in me rehashing them.

It was the 12 year old’s birthday party metaphor (described here) that first resonated with me. It illustrates that there are many domains in which it is not effective to design solutions in advance and from first principals: it is better to observe and gain experience of a complex domain and then build on that which is working and disrupt negative influences.

The emperical approach is also at the heart of XP and Scrum: that is the connection with Agile.

Apparently so ….

http://www.sei.cmu.edu/cmmi/adoption/pdf/jarvis-gristock.pdf

Brian Swan posed an interesting question the other night: how many successful standards derive from a standards body? I can’t think of any. All the ones that stick seem to be de facto: TCP/IP, driving on the left(\right), VCR cassettes, Microsoft Office Document formats, English grammar. Sure, some are now imposed but they did not start off that way.

Standards are important, but trying to design a technically superior solution from scratch is likely to be a waste of time: observe and formalise existing de facto standards.

I enjoyed Monday’s DSDM presentation at Agile Scotland. Alan Airth is a charming speaker and much of what he said made a lot of sense. If you have a heavyweight \ plan-based process, then DSDM would certainly be a marked improvement. However it didn’t seem to offer much different to the (de facto) Agile standards – Scrum and XP.

DSDM and Scrum occupy roughly the same space: the focus is on planning and interaction with the customer; in fact you could comfortably replace the words “DSDM” with “Scrum” on most of his slides.

The only contention was over the MoSCoW (must\should\could\won’t yet) categorisation of features; a few of us believe that a simple prioritised list works better. However within a movement that values “people over process” falling out over details of methodology seems contrary. From what I saw of Alan I am would expect his DSDM projects to be a success.

Assertion messages are useful when you need to locate just which assertion failed in a multiple assertion xUnit test. For readability and maintainability these should be short; I prefer not to repeat information that will be added by the test framework’s own failure message. Instead of

assertEquals(“There should be 23 widgets”, 23, testee.getWidgetCount());

assertEquals(“Widget count”, 23, testee.getWidgetCount());

When testing boolean values I favour using assertEquals as it is more expressive than assertTrue, reducing the information needed in the assertion message. Instead of writing

assertTrue(“Should have started”, testee.isStarted());

assertFalse(“Should not have finished”, testee.isFinished());

assertEquals(“Started”, true, testee.isStarted());

assertEquals(“Finished”, false, testee.isFinished());