I grew up at the dawn of personal computing. I was lucky enough to have been given a Commodore 64 as a christmas present and it blew my mind.

First Logo, then Basic, and before long I was scribbling down source code on reams of dot-matrix paper my step-Father brought home from work. I created screens that brought joy to my Mum by making “Happy Birthday” flash across our television screen in glorious 8-bit. I made a database to track every delivery of every test match in the Ashes Test series from England; an application that helped organise my Mum’s recipes so we wouldn’t lose all those great dishes my Hungarian Grandmother had scribbled down on bits of yellow, tabacco-stained paper; Mandelbrot sets – taking days to render until I realised that offscreen rendering was about 100 times faster - that had my friends jaws dropping at their beauty. I even copied verbatim the machine code from some magazine so that the kids at school could use a joystick to control simple sprites moving across the screen. I didn’t really understand what I was doing but they all thought I was a genius!

Eventually I started making a living writing software for very small Independent Software Vendors. Working in small teams, we produced amazing user experiences that I am still proud of 15-20 years later. It was as though I’d managed to con the world into paying me to do something that I really loved - creating software that put smiles on people’s faces.

For too many years now though, I have not really enjoyed my “chosen” profession. Sure, I’ve had moments here and there that have been thoroughly enjoyable but I’ve also had a sort of existential crisis every 12-18 months or so. “What was I doing this for?” “I’m clearly no good at this.” “Maybe I should find another line of work?”

I’d always been a spiritual person but my practices had been somewhat ad-hoc in nature. Then, in my late 20s, I met a group of people that seemed to speak my language. They belonged to a local church and so I went along. I converted soon thereafter and have been devout for more than a decade. However, it has been a somewhat rocky road. So much so that I recently went to see my local pastor.

I told him that no matter how often I practiced, how hard I prayed, or how diligently I followed the rituals, I still encountered problems I couldn’t resolve. That not everything I turned my hand to was a success. I told him that I was beginning to have my doubts. That there didn’t seem to be any scientific proof for any of his beliefs or for that matter anything written in the scriptures. That I sometimes preferred to meditate alone and that I found the gatherings to be succumbing to a kind of group-think. In reply he offered some words of advice.

He told me that no matter what, I should believe. That scientific evidence was unnecessary and that what mattered most was that I believed and followed all the practices as set out in the scriptures. He urged me to read and study the scriptures and to attend church gatherings to discuss my understanding with others wiser than I, who may have more insight into my spirituality. God is there, he said, to help those that are willing to take the time to understand his teachings. That I should not be disappointed if my prayers were not answered, and that not everything I do will turn out for the best, as I am not yet enlightened. For when I am able to worship fully and sincerely and in the correct manner, all will be revealed.

Actually, I’ve never been particularly spiritual, I’ve certainly never joined a church, and I think the only time I’ve ever had any kind of religious instruction was at High School – although I have read various parts of the Old and New Testaments. That said, I have been witness to this kind of discussion both in person and via blogs, Twitter, etc. only you’ll need to replace Religion with Agile, Pastor with Coach, Church with XP User Group, etc.

Unlike some languages, Ruby has no real way (that I know of) to define overloaded methods. Instead, you can specify that certain arguments are optional. For example, if we were to re-implement the Enumerable#reduce method, we might do so like this:

1
2
3
4
5

def reduce(memo = nil)
  return slice(1..-1).reduce(first) if memo.nil?
  each { |element| memo = yield(memo, element) }
  memo
end

That is, if no memo was specified, use the first element as the memo with a call to #reduce on the remaining elements of the array.

As far as I can tell, the most widely accepted format for agile user stories looks like this:

1
2
3

As a [role]
I would like to [action]
So that [reason for action]

I’m not entirely certain of the origins. Some have suggested Dan North and others have have suggested much earlier use. In any event, it’s use is so common I can’t recall a single “agile” project where that wasn’t the format but I’ve also never really been that comfortable with it and I’ve not really known why until recently.

Here’s an example:

1
2
3

As a domain novice
I want the domain experts names made prominent on a domain listing
So that I know who to turn to for help on a given domain

Though entirely contrived for the purpose of this discussion, it demonstrates the kind of stories people are inclined to write.

On the positive side, the format seems quite natural – people often have an implementation in mind and they can articulate it quite easily but find it much harder to articulate the intent. This seems to be reflected in the format with the primary focus (“I want”) expressed as the desired behaviour and the intent (“So that”) of conceptually lesser importance. The problem I have is the story centres around how the user will interact with the system and only then describes why. It presupposes an implementation with a cursory nod as to the user’s intent.

So¹, since my post on functional programming in object-oriented languages I’ve continued to tread the path with a mixture of gratification and despair. This morning the latter became overwhelming, I’d just had enough. My brain hurt and I just wanted to pump out some code, run it. I threw out the concepts I had been using as my guide and fell back on years of “old-school” object-oriented code.

Unfortunately, I was no more productive. In fact, I’d argue I was less productive. Things began to fail in weird and unexpected ways. The number of tests I needed to write to catch errors at least doubled. I soon returned to the comfort of my hybrid world.