My very very favourite author...

I have an entire shelf on my bookcase dedicated to the Discworld novels of Terry Pratchett. I acknowledge in passing that he has written other things, but his place in the history of sci-fi/fantasy is assured with this series. He has been consistently prolific in terms of his number of books, and their global sales, and I have absolutely loved his work from the time I laboured through The 'Colour of Magic' and 'The Light Fantastic' and reached 'Equal Rites', where we first met Granny Weatherwax. His fourth offering, 'Mort' remains one of my favourite Discworlds although latterly I think the way he has grown the characters of the Watch (Vimes, Carrott, Nobby et al) over a series-within-a-series has been bordering on genius...

Until about a year ago, I would have said that Pratchett was the subject of this article, but he is not...

Strangely, although I have little or no interest in the science fiction genre, my very very favourite author is almost always categorised in this way - A couple of years ago, someone lent me a copy of Ender's Game by Orson Scott Card and I absolutely loved it; In a 30 year career, Card has written about 50 novels, half a dozen short stories, written countless reviews and established a passionate fan-base on his website, upon whom he often calls for advice and critique of his unpublished work.

I thought I'd just give you a plot outline of the book with which Card is most closely associated, in many ways his 'Landmark Novel', Ender's Game.

Ender's Game is set at some point in the future on an Earth that until recently has been bubbling with political unrest. Several Baltic nations had formed a 'Warsaw Pact', and were challenging to become the dominant global force. The 'old powers' of America and the UK were recognised as being sleeping giants, no longer capable of competing against ambitious countries such as Russia, China or India.
All of this, however, has been put to one side, and the whole world has united in its fight against another threat... The 'Formics' (or "Buggers") are an alien nation that has fought the people of Earth on two occasions. The most recent battle was won by the humans by virtue of the genius of an old, half-Maori soldier named Mazer Rackham. The Battle Fleet must now put together a force to defend themselves against the impending alien attack, and to that end have established the 'Battle School' - an off-planet facility where children are taught to read, write and most importantly.. to fight.
The dominant, ambitious Peter Wiggin was rejected for Battle School, as was his empathic but equally brilliant sister Valentine. The Wiggins, then, are requested to produce a 'Third', in a time when strict population laws prevent such a thing, and Andrew 'Ender' Wiggin is born. At the tender age of six he is selected for Battle School and whisked away from his family (not before he has to fight off a jealous bully in his old school) and thrown into the exhilarating, often frightening world of Battle School. He soon learns that grades in the classroom count for little. Status and prestige at the Battle School depends entirely on your performance in the 'Battle Room' - a zero-gravity arena at the core of the School, where the children 'fight' each other in their designated Armies, using lasers and suits that 'freeze' when hit.
At the same time, Ender becomes obsessed with the 'Mind Game' - a role-play adventure game that forces the children to come up with innovative solutions to difficult situations; and all the time, he becomes increasingly aware that he is completely on his own... that no-one will be there to help him out when he's up against the wall, and that the only person he can truly rely on is himself...

I cannot really say more than that without spoiling the story, but I will say this... If you haven't already read it - do so; it's well worth it!!

Test-driven development

There's a fabulously ironical website called Waterfall 2006 - International Conference on Sequential Development (http://www.waterfall2006.com/). For those people who have suffered by waterfall development (either as protagonists or antagonists) it's well worth a read... I particulary like the title of a keynote speech "Put Testing Where It Belongs--At the End" (although technical document writers would possibly argue the point) testing has traditionally been the activity that must be endured once the clever people have had their input (i.e. created the specs and written the code).
As a code-monkey, this resonated with me; and only at a subconscious level did I acknowledge that something wasn't quite right about it. It wasn't until I became the 'Project Manager' - the guy who takes ultimate responsibility for delivery of a solution to a project sponsor, that I *honestly* started to care about the quality of what was being written...

I mean, come on! It compiles, so it probably runs... right? Ummm....

A couple of years ago I heard about test-driven development, and heard that it could increase the quality of developed code; but it was only last month that I actually started using it... It all started like this:
I needed to test some business-critical stored procedures we had written for a new client; They were quite complex, and in order to sign them off as fully functional, we had to check a susbtantial number of things. I didn't want to just run them and check the results.. It would have taken far too long, and I probably would've forgotten something, and I almost certainly would've forgotten to write down the details of what I was checking. So I told the developer I'm working with that I was going to write a program to automatically do the checking for me.
1/2 an hour later, I'd just about conceptualised a front-end in my head; How I was going to enter the tests; run the tests and check the results...
Then he says "You don't need to write a front-end for this testing program, you can just use NUnit..."
(We subsequently decided to use the Microsoft VS 2005 testing suite, but the prinicipal is exactly the same...)

So what is test-driven development? Wikipedia (http://en.wikipedia.org/wiki/Test-driven_development) describes it as "a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test"

The key word here, is first You write a test *first*; then you write the method to be tested... this means that when you're writing the actual code, you already have a very real goal to achieve for that small part of the project... you have to make your code pass the test!

There are some excellent articles that explore the 'how-to' side of TDD in greater detail, written by people with a wealth more knowledge and experience than I; (Google 'Test-Driven Development' and have a look...) but I thought it was worth sharing just how amazing the results are; and how much of a difference this can make to the whole software delivery process.

Consider the code behind Project Spaghetti... You know the one(s) I mean... the ones where you're petrified of tugging on this strand of spaghetti over on this side of the plate, because you have no idea how many meatballs are going to fall off the other side! The business says 'I just need that commission calculator to consider price-breaks and bulk discounts'; but you know for a fact that they asked you to amortize commission calculations per product line across months for some product categories and quarter for others... You just got the damn thing working (cos the contractor that wrote the first version was clearly a total bandit, and you definitely wouldn't have written it like that...) and you really don't want to touch it!
Now consider an automated set of tests that, should they all pass, *definitively prove* that the code is still functionally correct... All of a sudden, you're not scared of adding that extra piece of functionality; or subtly changing the funcationality you've got because your business rules just changed... All you have to do is:
- create/alter the test criteria in your unit tests
- Run the new/altered tests; note that they fail...
- Write the new code
- Re-run the tests... And if all of a sudden you're seeing tests failing left, right and centre; then you throw away your changes, and think about how to solve the problem without touching the fragile code in the middle!
But here's the thing... You spotted that you inadvertantly broke something else *before* it went into a production envrionment (and the system users starting ringing helpdesk's phone off the hook) and *without* paying the QA team to perform a month's worth of regression testing...

As a man who seeks the eutopian ideal of delivering perfect software solutions; this really does resonate with me...

For those of you (like, until very recently, me) who have yet to put this time-saving, labour-saving paradigm into practise, remember this... "A dead fish can't swim; But it can float down a waterfall"

The IRB has ruined my favourite winter sport...

When I moved to NZ in early 2003, England had one of the best rugby teams in the world... I sometimes wonder if it's their inglorious decline that has ruined the appeal of this country's premier sport (and, dare I suggest, national obsession?) - and the answer has to be... no (although it obviously hasn't helped!)

As a child, I always believed that an average game of rugby league was always good value... lots of hit-ups, tackling, ball-in-hand running... all the things that make a game good to watch; But I genuinely believed that the best a game of league had to offer could not compare with the aesthetic beauty of a free-flowing game of union; I remember watching the famous 1973 All Blacks vs Barbarians at school; that wonderful try finished off by Gareth Edwards!

So what's happened? Why is it that as a spectator, I have turned away from Rugby, and this season am more likely to be seen at Mt Smart stadium (home of the Warriors in the NRL) than Eden Park?

I'll try and answer this by giving you two examples; one in union and one in league.

Firstly, union: In an attempt to make the scrums safer (I suspect,partly in response to the Matt Hampson incident), the IRB introduced a new, 4-stage engagement process at scrum time. To ensure opposing packs are suitably distanced from each other, the props must 'touch' each others arms before engaging. It just hasn't worked. These new scrum laws have *not* made scrum-time quicker, simpler, safer. The referees are *still* having to constantly reset scrums and the spectacle (let's not forget, Rugby is a spectator sport!) has been seriously compromised. And yet the new law persists...

Now consider the law change introduced at the start of the 2007 NRL season. In an attempt to combat the use of 'shadow' runners, the referees were instructed to confer with the TMO (Third Match Official, watching the replays on screen) to ensure that no defender had been impeded off the ball, before awarding a try. Great! Only problem was, teams who had scored legitimate trys were subsequently being penalised because some defender *who had no chance of making a tackle anyway* had been blocked by a dummy runner... It came to a head around week 6 or 7, when 5 or 6 perfectly good tries had been scored (2 by the Warriors!), but on all occasions the attacking team were penalised for the above infringement. So what did the governing body do? They gathered all the CEO's of the competing franchises together on a conference call, and took a vote... 'should we allow referees to use their discretion as to whether the defender would have made the tackle if he hadn't been impeded?' unequivocally they voted 'yes' - and by that very same weekend; before another game had been played in the competition; the amendment was in place.

I wonder where the IRB would be now (Week 13) if they had the same issue? Almost certainly in the same place as they are with the much-ridiculed new scrum laws... Scratching their behinds and contemplating how much money they can make out of France 2007...

Of course, the last thing to say for now about this switch in allegiance is that I'm now on the roller-coaster ride that is: Being a Warriors fan. But more on that another time...