I am Paul Wilson; Mere Complexities Limited, sells my consulting, coaching, and coding services. I am passionate about Agile, particularly Test Driven Development.
Freemarket cooperation
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 quotes from the waterfall
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.
Cynefin
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.
DSDM
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.
All standards are de facto
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.
Minimal assertions
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());
I would write
assertEquals("Widget count", 23, testee.getWidgetCount());
On failure
Junit tells you all you need to know:
junit.framework.AssertionFailedError: Widget count expected:<23> but was:<22>.
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());
I prefer
assertEquals("Started", true, testee.isStarted());
assertEquals("Finished", false, testee.isFinished());