Skip to content

“Common Objections to TDD” coming to Agile North 2012

If you missed my talk at ACCU 2012, you now have another chance. I’ll be presenting it at Agile North (Preston) on June 29th.

There is a chance that it will be recorded, which would be great, because the slide deck doesn’t really work on its own.

“Common objections to TDD” slide deck, now uploaded

Last week I presented my session at ACCU 2012 to a packed audience in an overheated room. Here is the slide deck

TDD Survey now closed

Thanks to all of you who contributed to the survey.

I now have quite a bit of work collating your input, which I hope to
finish before the end of April. I’ll then blog the results.

I’ll also be presenting a session on “Objections To TDD” at the ACCU
conference in Oxford, UK

HomePlug non-interoperability

TL;DR; Homeplug devices can be a great way to network your house, but they may not all interoperate smoothly.

Like many people I live in a house that was built before networks were an essential part of family life. A common solution is WiFi, but that comes with its own drawbacks, not least the flakey nature of the connection with many household configurations.

Never mind. Clever engineers came up with HomePlug. The idea is that you send your network traffic down the mains cable that runs through your house. HomePlug devices simply plug into the wall and offer a standard RJ45 socket to plug your network cable into. You can plug as many HomePlug devices into your ring mains as you like, and the whole thing just behaves like a network. There’s the Homeplug Powerline Alliance that certifies compliance to the standard, and everything should just work.

The original standard, Homeplug 1.0, was released back in 2001. This was followed by Homeplug AV in 2005. These two standards were never meant to be compatible, and aren’t. However, all Homeplug 1.0 devices should interoperate, and all Homeplug AV devices should interoperate too.

I’ve been running 4 HomePlug AV devices in my house for the past 5 years. The ADSL router plugs into one, making internet connectivity possible throughout the house. The Squeezebox player uses another to access my music collection. There’s one in the office for the PC and another in my daughter’s room for important things like Facebook. No problems until the arrival of my son’s Xbox 360.

Rather than buying another simple HomePlug device I looked around and found a Netgear XAV 1004 4 port HomePlug switch. Great idea, but on plugging it in it failed to work in a fairly conclusive way.

I logged a ticket with Netgear’s customer support. Each response from them began “After reviewing the information you provided, I have a better understanding of your issue,” which was odd, because in the end (after several e-mails) they clearly hadn’t understood, and ended up by saying “we apologize for the inconvenience caused due to this product as it is not compatible with your setup.” Ho hum – send it back to Amazon for a refund.

I then took it up with the Powerline Alliance, the industry body who certify Homeplug devices. They did eventually respond to my enquiry, and (again after several e-mails) they ended up by saying:

“There are many reasons why a device may not operate on your network, such as the length/quality of the wire, or the presence of other non-PLC devices. Therefore, there is no way for us to ‘guarantee’ that a device will work on your network. However, HomePlug certified devices have been tested to interoperate. If you purchase a product, and still have issues, the best course of action is to contact the manufacturer or retailer.”

This may be quite true, but is of little use to the end user!

Meanwhile, some web searching turned up this very interesting web page. There’s a lot of information on this page, and it’s not particularly easy to consume, but the bottom line seems to be:

  • All commercially available Homeplug devices are based on chips manufactured by Intellon
  • There have been several major revisions of the chips and the firmware
  • The tools for updating the firmware (and the firmware updates themselves) are not advertised to end users or known about by first line support staff
  • The tools for updating the firmware are intended for specific firmware versions.
  • It’s not clear which chipsets can be updated to which firmware versions. Do it wrong and you may end up with a brick.

My take away from this is that Homeplug is fine if you buy all the adapters you need from the same manufacturer at the same time. Expanding your network later may not go as smoothly as you’d like.



Singleton, Design Patterns and Pattern Languages

Singleton has been a thorn in the side of proponents of design patterns ever since it saw the light of day in the GoF book.

I recently came across this short presentation I wrote on the subject of Design Patterns in general and Singleton (and its alternatives) in particular:



TDD Survey goes live

Last night my TDD Survey form went live at

It’s a very basic, free-text form, designed to gather reasons why more people don’t practice TDD. After all, TDD is one of the foundational agile practices that has been promoted heavily since the early XP days, but it’s also one of the practices that many agile teams choose to ignore.

The survey will run till the end of March 2012. Results will then be posted on this blog.

The survey will also be used as the basis of a session that I’m running at ACCU 2012 in Oxford, UK ( ) and the slides will be made available at the beginning of May 2012

Fun with FitNesse

I’ve dabbled a bit with FitNesse over the years, but have recently concentrated more on unit testing (with GoogleTest and GoogleMock). I’m now working on a Java web app and FitNesse seems like just the thing for putting some acceptance tests in place. So, I downloaded FitNesse and started looking around for a fixture that would talk http (and maybe https). I quickly came across a fixture called HtmlFixture, which is built on top of HtmlUnit. Download and installation was trivial and I was soon up and running with my straw-man acceptance test.

Of course, this is just the point at which problems start. I wanted to build the URL to retrieve within the body of the test, based on the test setup – not an unreasonable requirement. HtmlFixture requires the URL to be specified in the first cell of the first row after the table heading, and I couldn’t find a way of generating the URL in a preceding table and then using it HtmlFixture. FitNesse has enhanced the ColumnFixture to allow storing and retrieving values as named ‘Symbols’, but HtmlFixture is derived from Fixture itself, so no joy there (although more on this later).

And, while there is lots of ‘documentation’ about FitNesse it does suffer from that peculiar affliction of all Wikis I’ve dealt with – rot. The information is hard to find, non-authoritative and sometimes down-right confusing (for instance FitNesse now runs against EITHER a Slim server or a Fit server). There’s also a book “Fit for developing software”, by two of the original writers of the software, but this was published in 2005 and is a bit long in the tooth – though still indispensable. The index also leaves a lot to be desired.

Meanwhile, the HtmlFixture site is billed as being “Improved”, but the Command Reference starts with the not-entirely-confidence-inspiring sentence: “The following documentation is accurate, but incomplete.” And indeed, it lived up to this promise, so, it was off to Sourceforge to have a look at the one true documentation – the source code.

Next day: time to write some code:

  • Derive a fixture from HtmlFixture.
  • Override doTable
    • Do preprocessing to build the required URL
    • Manipulate the Parse tree to put the URL where HtmFixture’s doTable method expects it
    • Pass the Parse tree to super.doTable

 The Parse class is part of Fit and, though the source code is open for inspection, it was a diagram in the ‘Architecture’ section at the back of the “Fit for developing software” book that actually helped me traverse the tree successfully. Without that I know I would have struggled for quite a bit longer.

The test now works as expected, and all is good. Closer inspection of the source and documentation of HtmlFixture show that there is functionality to support the use of Symbols as variables. This should allow me to refactor the code, so that the URL building gets done in, say, a SetUpFixture, leaving a vanilla HtmlFixture to execute the http GET and check the response.