Ever since attending code retreat at Bletchley Park (the UK leg of Corey Haines’s code retreat tour) last year, I’d been vaguely intending to try and run an internal one at work. I finally got round to it this month, when a few people expressed an interest in a code retreat as a one-off alternative to the usual developer conferences we run a couple of times a year. I thought I’d share my experiences facilitating a code retreat for the first time, in case it’s helpful to anyone thinking of doing the same.

Beforehand

The “official” code retreat site has some good information on things to consider when hosting and facilitating. I suspect organising an internal company event is easier than a public one, because hopefully you’ll have a venue available and you won’t need to worry about sponsorship. The only one of Corey’s rules I ignored was the one about giving people decent food at lunchtime, but we did at least manage to beg enough budget (thanks Mel!) to be able to provide cheap Tesco sandwiches at lunchtime and a few random snacks and coffee during the day. I don’t feel too bad because rather than asking people to “come out at eight in the morning to spend the day coding”, we were giving them an excuse to spend a work day away from their projects, getting paid to practice.

We also planned to start at nine o’clock rather than the traditional eight. I think for public events the early start, usually on a Saturday, is a good way of selecting only people who really want to take part, but running it at work I wanted to swing the balance a bit towards encouraging people to come (I work on a large site with probably a couple of hundred developers scattered amongst the 3000-odd BT people, and part of the motivation for running this kind of event is to try and put developers from different teams in touch with each other).

With a bit of publicity via mailing lists and posters on site, 27 people had signed up. That seemed like about the right number, although I had no idea how many of those would turn up, or whether anyone would turn up without registering. I turned up at the office in plenty of time, and was lucky enough to get some last-minute tips from the master:

Getting started

As it turned out we had a few glitches to deal with before we could get going – firstly the venue was locked and we only managed to get in because Rupert knew how to find the secret back entrance, then Adam and Anna got kicked out of Tesco for a fire alarm while buying the food – so we ended up starting at closer to 9.30.

Potentially the biggest disaster though was that the hopper was missing from the coffee machine (most likely locked away to stop people like us using it with our own beans instead of paying for catering). Fortunately it takes more than a little detail like that to defeat a room full of engineers, and we soon had a workaround in place using a plastic cup with the bottom cut out.

Once the caffeine supply was assured and we were finally ready to start, I gave a quick presentation covering the purpose of the day, the four rules of simple design and Conway’s game of life:

First session

With everyone hopefully having a reasonable idea of what was going on, people paired up and started the first session. There were about 25–30 people (I forgot to count), split something like 70:20:10 between Java, Ruby and Groovy. In the first session, as expected, everyone was mostly just getting a feel for the problem, and realising that it’s not quite as simple as it appears from the list of rules.

After 45 minutes, I put on my best exam invigilator voice and got everyone to stop typing, delete their code and gather round. Pairs were split roughly evenly between those that started with a grid and those that started with a cell, and we had a short discussion about how a grid approach using a two-dimensional array fitted in with the “infinite grid” constraint. Some of those who had started from a cell were thinking about approaches for allowing cells to know about their neighbours, but no-one had got that far yet.

Mixing it up

For the second session, I suggested that those that had started with a grid tried starting from a cell instead, and vice versa. There were also quite a few people who wanted a chance to try Ruby, so they tried to grab the rubyists before anyone else did. Little did they know that they would find themselves exposed to Vim (and in some cases Mac OS X) at the same time, but that’s just a bonus.

In general people who tried both seemed to prefer the cell approach, partly because it made it easier to test-drive the rules. With a grid, people found they were having to implement some kind of to_string or render method to allow the transformed grid to be compared with the expected result. The biggest puzzle with the cell approach was how to handle the relationship between multiple cells.

I introduced a list of possible constraints people might want to consider to make things more interesting:

• No if statements (or other conditionals).
• No loops.
• No methods longer than five lines (or four, or three…)
• No more than three methods per class.
• No ‘naked’ language primitives.
• No built-in data structures.

I also attempted to explain TDD as if you meant it, in case anyone fancied giving it a go. Unfortunately my description was rather garbled, not helped by the fact that I’m not sure I fully understand it myself (I’m still annoyed that I picked the wrong track at SC2009 and missed Keith’s original presentation of the exercise, and it turns out Adam made the same mistake at SPA2010).

Session three

By the third session several pairs were starting to experiment with storing cell objects either in a set (with each cell knowing its position) or a hash, keyed by position. Some people used a comma-separated “x,y” string as the key, but with a bit of prodding most ended up replacing it with a point class of some kind.

One pair decided to start with a single cell, then initialise other cells with their neighbours. This initially seemed promising, but soon led to complications with circular references, as well as the need to keep dead cells around to maintain a connection between cells with space between them.

Another pair started developing the rules with a cell class, and initially had an alive? method which performed the life calculation. After some discussion they split the class into two – one for a living cell and another for a dead one. This removed a level of nesting from the calculations (which ended up in a different method), but interestingly left alive? in both classes, hardcoded to true and false respectively. We decided that this would have looked less odd in Java, where the method would have been declared abstractly in a superclass or interface.

One pair had decided to try implementing a solution with no if statements, but resorted to cheating by using a case instead!

In general, a lot of people – particularly those new to TDD – were starting to get frustrated, feeling like they were just getting to the point where they were “about to start the interesting bit” as the 45 minutes were up. I told them that we’d just have two sessions after lunch rather than three, with the second session lengthened to give people a chance of implementing a working game.

Fourth – and as it turned out final – session

After lunch we started the fourth session, but it soon became clear that several pairs had already decided to abandon TDD and clean code in favour of trying to solve the problem. I completely understand how they felt – I wasted most of the sessions at the code retreat I attended simply pushing for the finish line instead of letting it go and concentrating on perfecting the internal quality of the code – but it seemed like we’d lost sight of the key goal of the day a little. I suspect I’m mostly to blame for that, and I’m sure a more experienced facilitator could have done a better job of gently guiding people in the right direction. Anyway, it seemed sensible to bow to the inevitable, let everyone carry on for another 45 minutes and wrap up a bit earlier than planned.

With the extra time, a few pairs did manage to get a working implementation, but the prize for the most impressive (cancelled out by a booby prize for abandoning TDD and neglecting the quality of their code!) goes to Jon and Jia Yan, who produced an SWT app that allowed graphical editing of the grid, variable speed and saving and loading files. They used the “set of live cells” approach, with an effectively infinite grid. Resizing the window on screen allowed you to show or hide cells, but the ones off the edge of the visible area continued to multiply.

Matthew and Rupert decided to look at someone else’s solution in Clojure, to understand how a functional approach using list comprehensions can lead to a very concise solution. They also played around with a Ruby version using the same techniques. Looking at the Clojure code led to a slightly rearranged version of the rules for life at a particular location after a clock tick:

1. Cells which had three neighbours are alive
2. Cells which had two neighbours are unchanged
3. All other cells are dead

Paul, stuck on his own after his pair got dragged off onto a conference call (the perils of being a senior manager!), had a play with TDD as if you meant it. I think by the end of the session he was starting to get somewhere. Further than me, at any rate.

Wrapping it all up

After letting Jon show off a glider gun running in their SWT universe, we gathered round for the closing circle, asking everyone what they’d learned, what had surprised them, and what they’d do differently back at work on Monday as a result. Probably the most common comments revolved around the fact that neither of the two most obvious solutions turned out to be the best, suggesting that it’s worth spiking a few alternative approaches before heading blindly off down what may be a blind alley. Quite a few people were new to pairing, TDD or both, and generally seemed to agree that both provided benefits, although a couple of people felt that TDD was making things take much longer. Reassuringly, of the pairs that had abandoned TDD to concentrate on trying to get a working solution, most had found themselves descending into confusion without the tests to guide them.

Final thoughts

Overall, the event seemed to be a success. For quite a few people this was their first experience of TDD, and the opportunity to get first-hand experience by pairing with someone more experienced seemed to be useful. I was particularly pleased to see someone who’s recently come back into software development after a long time away doing a great job of holding his pair back from rushing into implementation without a failing test.

On a less positive note, I didn’t feel we really concentrated enough on “perfect” code and the four rules of simple design. I know from experience that it’s hard to let go of the natural desire to try and finish solving the problem, and I felt that a lot of people were getting frustrated enough without me peering over their shoulders picking holes in their code (however nicely I tried to do it). Perhaps this is a case of horses for courses, with the concentration on design perfection more suitable for a different mix of participants, or perhaps it just reflects my lack of experience facilitating this kind of event.

Also, I don’t think we really had enough sessions for the code retreat magic to start kicking in properly. We’d planned to have the recommended five or six, but a combination of the late start and a general loss of direction after lunch reduced that to four (with the fourth being double-length).

The important thing, of course, is that people learned something by participating, and I hope that was the case. Maybe we’ll do another one one day, and use the experience of this one to make it even better.

BT: A case study in agile programming

"Given that we don't have the Internet or any software, how are we supposed to work with Open Source?"

Doc Searls's response:

"The current policy is freaking insane! It's utterly inconsistent with BT's strategy, and I can't understand why anyone would want to come and work here... Maybe we ought to go and storm the head office or something."

Technorati Tags: policy, internet, open source, doc searls

In other words, agile developers do just as much designing as those still following waterfall methods, but we do it at the same time as writing the code.

Reflecting afterwards, I realised that I've been phrasing the message the wrong way. As anyone who really 'gets' test-driven (and particularly behaviour-driven) development knows, it's not really about the testing, but about the design process. A waterfall 'designer' starts from an understanding of the problem and builds up some kind of model for a solution, which they then pass on to the implementors An agile developer does exactly the same, but the language they use for the model happens to be executable source code rather than documents or UML. This choice of modeling language has the rather large benefit of being testable, and once your design is finished, you're done. No need for someone to try to interpret and implement it. No scope for misunderstandings between designer and developer. No danger that the design is incomplete, or that part of it turns out to be unworkable.

It's not that we start writing code and design as we go along.

We are always designing – we just write the code as we go along.

Technorati Tags: agile, tdd, bdd

This time, the challenge is to come up with some Ruby code that converts a positive integer to its English language
equivalent. For example:

1 => one

10 => ten

123 => one hundred and twenty three

10,456 => ten thousand four hundred and fifty six

1,234,123 => one million two hundred thirty four thousand one hundred and twenty three

The code should work from numbers 1 - 10,000,000,000 (ten billion) but if it works for bigger numbers its all good.

For an extra challenge, when the strings for the numbers for 1 - 10,000,000,000 are sorted alphabetically, which is the
first odd number in the list?

I thought it might be interesting (to me, at least!) to record the process I go through to reach the solution, rather than just sharing the finished article. I'm using a behaviour-driven approach, although the process for writing a single method obviously doesn't touch on a lot of the wider aspects of BDD.

So here it is, warts and all (I'm writing this as I go along, so I have no idea how long this post is going to get, or whether I'll even arrive at a solution at all!)

First, let's describe the very simplest bit of behaviour: if I feed in 1, the output should be 'one'. The obvious approach is to add a to_words method to the Integer class. Obvious to those who have their Ruby heads on, that is – to those more used to languages like Java, it probably sounds like the ravings of a mentalist).

Let's create a specification file called to_words_spec.rb (I'm using rspec):

What happens when we run it?:

$ spec to_words_spec.rb
F

1)
NoMethodError in '1.to_words should be 'one''
undefined method `to_words' for 1:Fixnum
./to_words_spec.rb:3:

Finished in 0.009689 seconds

1 example, 1 failure

No surprise there. I'll create another file, to_words.rb, where I define the method (for now I'll leave it empy):

Require this at the top of to_words_spec.rb:

And run the spec again:

F

1)
'1.to_words should be 'one'' FAILED
expected "one", got nil (using ==)
./to_words_spec.rb:5:

Finished in 0.009579 seconds

1 example, 1 failure

OK, so the method's there now, but we haven't got a return value. The easiest thing to do to make this spec pass is to just hardcode the return value:

.

Finished in 0.010926 seconds

1 example, 0 failures

The fact that we've hardcoded it means we need another example to describe the required behaviour for different inputs:

.F

1)
'2.to_words should be 'two'' FAILED
expected "two", got "one" (using ==)
./to_words_spec.rb:11:

Finished in 0.019927 seconds

2 examples, 1 failure

Let's make the code a bit more intelligent. I think I'll use an array to hold the names of the digits, but for now I'll only populate it with enough data to pass the spec.

..

Finished in 0.010498 seconds

2 examples, 0 failures

Now I could paste the same example in a few times and change the numbers, but that would be a bit ugly. This looks better, and I think it's still obvious what's going on:

FF.F.FFFF

1)
'5.to_words should be 'five'' FAILED
expected "five", got nil (using ==)
./to_words_spec.rb:8:

…

7)
'4.to_words should be 'four'' FAILED
expected "four", got nil (using ==)
./to_words_spec.rb:8:

Finished in 0.021579 seconds

9 examples, 7 failures

If I add the missing numbers, it should pass.

If you add the -f s (short for --format specdoc) option, it's easy to see the examples that are being dynamically generated:

$ spec -f s to_words_spec.rb

5.to_words
- should be 'five'

6.to_words
- should be 'six'

1.to_words
- should be 'one'

7.to_words
- should be 'seven'

2.to_words
- should be 'two'

8.to_words
- should be 'eight'

3.to_words
- should be 'three'

9.to_words
- should be 'nine'

4.to_words
- should be 'four'

Finished in 0.020708 seconds

9 examples, 0 failures

Because I'm using a hash, the examples aren't run in numerical order. It's not ideal, but I don't think it's worth complicating the spec to fix it.

An interesting point from the previous failures though – what should it do if the number falls outside the range it can cope with? For the sake of argument, I'll make something up. To start with, the only numbers it can handle are one to nine: I'll change the example as I expand the range. I'll put 10,000,000,001 in now anyway.

.........FFFFF

1)
'-123.to_words should be '?'' FAILED
expected "?", got nil (using ==)
./to_words_spec.rb:17:

2)
'-1.to_words should be '?'' FAILED
expected "?", got "nine" (using ==)
./to_words_spec.rb:17:

3)
'0.to_words should be '?'' FAILED
expected "?", got "zero" (using ==)
./to_words_spec.rb:17:

4)
'10.to_words should be '?'' FAILED
expected "?", got nil (using ==)
./to_words_spec.rb:17:

5)
RangeError in '10000000001.to_words should be '?''
bignum too big to convert into `long'
./to_words.rb:5:in `[]'
./to_words.rb:5:in `to_words'
./to_words_spec.rb:17:

Finished in 0.026465 seconds

14 examples, 5 failures

Hmm, a few unexpected things going on here. Let's fix the easy ones first by just returning a question mark if we don't find a value. Also, putting zero in that numbers array when none of the examples required it has come back to bite me. I'll change that to nil.

..........F..F

1)
'-1.to_words should be '?'' FAILED
expected "?", got "nine" (using ==)
./to_words_spec.rb:17:

2)
RangeError in '10000000001.to_words should be '?''
bignum too big to convert into `long'
./to_words.rb:4:in `[]'
./to_words.rb:4:in `to_words'
./to_words_spec.rb:17:

Finished in 0.024623 seconds

14 examples, 2 failures

Still a couple of problems. The first one is obviously caused by the fact that in Ruby a negative index on an array means 'count back from the end', so I'll explicitly check for zero or negative numbers.

.............F

1)
RangeError in '10000000001.to_words should be '?''
bignum too big to convert into `long'
./to_words.rb:5:in `[]'
./to_words.rb:5:in `to_words'
./to_words_spec.rb:17:

Finished in 0.024365 seconds

14 examples, 1 failure

You may have noticed I've been leaving that one until last. Now everything else works, it's time to bite the bullet and figure out exactly what's going on here. It obviously doesn't like doing numbers[10000000001], but why is it converting it to a long? I didn't even think Ruby had a long type!

Time to RTFM (Incidentally, I always use gotapi for browsing and searching API docs). No mention of longs in the description, but a peek at the source shows that the underlying C code is doing things like beg = NUM2LONG(argv[0]);. Not to worry though – it's not like I'm going to be just creating an array of all possible values, so I'll just check the upper range explicitly too.

..............

Finished in 0.023524 seconds

14 examples, 0 failures

Right, now we can get back to the real task. The words for 10–19 are mostly irregular, so I'll just add them to the list for 1–9.

.....F.FF.F.F.F.F.F..F.F

1)
'16.to_words should be 'sixteen'' FAILED
expected "sixteen", got "?" (using ==)
./to_words_spec.rb:19:

…

10)
'10.to_words should be 'ten'' FAILED
expected "ten", got "?" (using ==)
./to_words_spec.rb:19:

Finished in 0.040177 seconds

24 examples, 10 failures

I'll just add them to the array in the code too (remembering to increase the allowable range):

...F....................

1)
'10.to_words should be '?'' FAILED
expected "?", got "ten" (using ==)
./to_words_spec.rb:7:

Finished in 0.039858 seconds

24 examples, 1 failure

Oops, forgot to modify the examples for out-of-range behaviour.

# Examples of unhandled numbers
........................

Finished in 0.060643 seconds

24 examples, 0 failures

Now let's do 20, 30 etc. Once they're done, that should be it for the actual numbers, and we can start stringing them together.

........................FFFFFFFF

1)
'60.to_words should be 'sixty'' FAILED
expected "sixty", got "?" (using ==)
./to_words_spec.rb:29:

…

8)
'70.to_words should be 'seventy'' FAILED
expected "seventy", got "?" (using ==)
./to_words_spec.rb:29:

Finished in 0.045908 seconds

32 examples, 8 failures

There's going to be extra logic required for numbers over twenty (so far we're only looking at the round ones, and ignoring 21, 22 etc), so I'll split them out in the code.

This time I remember to change the out-of-range example too:

................................

Finished in 0.053969 seconds

32 examples, 0 failures

Looking good. Now to start building up more interesting numbers. I'll word the examples a bit differently from now on, so that it's obvious what general behaviour they're actually describing. Let's start with two digit numbers.

................................F

1)
'A two-digit number above 20 that's not divisible by ten, in words should be '-'' FAILED
expected "twenty-one", got "twenty" (using ==)
./to_words_spec.rb:36:

Finished in 0.051832 seconds

33 examples, 1 failure

First of all, I'll take the naive approach of adding the hyphen and the units number every time.

........................FFFFFFFF.

1)
TypeError in '60.to_words should be 'sixty''
can't convert nil into String
./to_words.rb:13:in `+'
./to_words.rb:13:in `to_words'
./to_words_spec.rb:29:

…

8)
TypeError in '70.to_words should be 'seventy''
can't convert nil into String
./to_words.rb:13:in `+'
./to_words.rb:13:in `to_words'
./to_words_spec.rb:29:

Finished in 0.049627 seconds

33 examples, 8 failures

My new example passes, but as expected I've broken a load of others. This is good, because it shows that I'm building up a good test coverage. A slightly more sensible implementation:

.................................

Finished in 0.04624 seconds

33 examples, 0 failures

It's probably worth trying another couple of numbers too, including some boundary conditions. I'm not really sure what text to put in the specs now though, as they're just different examples of the same behaviour. I could create a new context and call it 'Another two-digit number…', but I think I'll just give them both the same name. This isn't something I've done before, so I haven't decided yet whether it's a good thing or not. I'll factor out the duplication as I go.

....................................

Finished in 0.048549 seconds

36 examples, 0 failures

Good, it still works. I could add more, but I think that's enough.

Next thing to attack is probably the round hundreds. I've decided there's no point in having to change the out-of-range example every time, so I've changed it to only try the really big number.

Note how I've used to_words itself in the matcher argument. I can get away with that because I've already tested its behaviour for the numbers I'm using.

...................................FFF

1)
'A three-digit number that's divisible by one hundred, in words should be ' hundred'' FAILED
expected "one hundred", got "?" (using ==)
./to_words_spec.rb:46:

2)
'A three-digit number that's divisible by one hundred, in words should be ' hundred'' FAILED
expected "five hundred", got "?" (using ==)
./to_words_spec.rb:46:

3)
'A three-digit number that's divisible by one hundred, in words should be ' hundred'' FAILED
expected "nine hundred", got "?" (using ==)
./to_words_spec.rb:46:

Finished in 0.049282 seconds

38 examples, 3 failures

Should be easy enough…

......................................

Finished in 0.048804 seconds

38 examples, 0 failures

Let's fill in the gaps between the hundreds.

......................................FFFF

1)
'A three-digit number that's not divisible by one hundred, in words should be ' hundred and '' FAILED
expected "one hundred and one", got "one hundred" (using ==)
./to_words_spec.rb:54:

2)
'A three-digit number that's not divisible by one hundred, in words should be ' hundred and '' FAILED
expected "one hundred and fifty", got "one hundred" (using ==)
./to_words_spec.rb:54:

3)
'A three-digit number that's not divisible by one hundred, in words should be ' hundred and '' FAILED
expected "six hundred and sixty-six", got "six hundred" (using ==)
./to_words_spec.rb:54:

4)
'A three-digit number that's not divisible by one hundred, in words should be ' hundred and '' FAILED
expected "nine hundred and ninety-nine", got nil (using ==)
./to_words_spec.rb:54:

Finished in 0.056888 seconds

42 examples, 4 failures

.........................................F

1)
'A three-digit number that's not divisible by one hundred, in words should be ' hundred and '' FAILED
expected "nine hundred and ninety-nine", got nil (using ==)
./to_words_spec.rb:54:

Finished in 0.050711 seconds

42 examples, 1 failure

That's odd. Oh, I see – there's an extra dot in the range (100...999 instead of 100..99), which means it excludes the last number. Let's fix that and run it again.

..........................................

Finished in 0.054811 seconds

42 examples, 0 failures

That's better.

From now on, it ought to be plain sailing. Each group of three digits needs to get converted on its own, then have the appropriate multiplier ('thousand', 'million' or 'billion') appended (and maybe a comma). Let's start with the thousands.

..........................................FFFF

1)
'A four, five or six-digit number that's divisible by one thousand, in words should be '
 thousand'' FAILED
expected "one thousand", got nil (using ==)
./to_words_spec.rb:62:

…

4)
'A four, five or six-digit number that's divisible by one thousand, in words should be '
 thousand'' FAILED
expected "nine hundred and ninety-nine thousand", got nil (using ==)
./to_words_spec.rb:62:

Finished in 0.072061 seconds

46 examples, 4 failures

..............................................

Finished in 0.053842 seconds

46 examples, 0 failures

..............................................FFFF

1)
'A four, five or six-digit number that's not divisible by one thousand, in words should be ' thousand, '' FAILED
expected "one thousand, two hundred and thirty-four", got "one thousand" (using ==)
./to_words_spec.rb:70:

…

4)
'A four, five or six-digit number that's not divisible by one thousand, in words should be ' thousand, '' FAILED
expected "nine hundred and ninety-nine thousand, nine hundred and ninety-nine", got "nine hundred and ninety-nine thousand" (using ==)
./to_words_spec.rb:70:

Finished in 0.05905 seconds

50 examples, 4 failures

..................................................

Finished in 0.056001 seconds

50 examples, 0 failures

Flying along! There's a special case we need to cover before we move onto the millions though – where there are no hundreds, so the comma becomes an 'and' (like 'two thousand and seven').

..................................................FFF

1)
'A four, five or six-digit number that's not divisible by one thousand but has no hundreds, in words should be ' thousand and '' FAILED
expected "one thousand and twenty-three", got "one thousand, twenty-three" (using ==)
./to_words_spec.rb:78:

2)
'A four, five or six-digit number that's not divisible by one thousand but has no hundreds, in words should be ' thousand and '' FAILED
expected "twenty-three thousand and one", got "twenty-three thousand, one" (using ==)
./to_words_spec.rb:78:

3)
'A four, five or six-digit number that's not divisible by one thousand but has no hundreds, in words should be ' thousand and '' FAILED
expected "three hundred and forty-five thousand and ninety-nine", got "three hundred and forty-five thousand, ninety-nine" (using ==)
./to_words_spec.rb:78:

Finished in 0.060685 seconds

53 examples, 3 failures

.....................................................

Finished in 0.057426 seconds

53 examples, 0 failures

The millions should be pretty much the same, so I'll do all the specs at once.

.....................................................FFFFFFFFFFF

1)
'A seven, eight or nine-digit number that's divisible by one million, in words should be ' million'' FAILED
expected "one thousand million", got nil (using ==)
./to_words_spec.rb:86:

…

11)
'A seven, eight or nine-digit number that's not divisible by one million but has zeroes from hundreds of thousands down to hundreds, in words should be ' million and '' FAILED
expected "three hundred and forty-five million and ninety-nine", got nil (using ==)
./to_words_spec.rb:103:

Finished in 0.074188 seconds

64 examples, 11 failures

................................................................

Finished in 0.066676 seconds

64 examples, 0 failures

Just the billions to go, and we're done! I might as well let it handle up to 999,999,999,999 – forcing it to stop at 10,000,000,000 would probably be harder.

................................................................FFFFFFFFFFF

1)
'A ten, eleven or twelve-digit number that's divisible by one billion, in words should be ' billion'' FAILED
expected "one billion", got nil (using ==)
./to_words_spec.rb:111:

–

11)
'A ten, eleven or twelve-digit number that's not divisible by one billion but has zeroes from hundreds of millions down to hundreds, in words should be ' billion and '' FAILED
expected "three hundred and forty-five billion and ninety-nine", got "?" (using ==)
./to_words_spec.rb:128:

Finished in 0.105984 seconds

75 examples, 11 failures

The complete working code:

And just to prove it:

...........................................................................

Finished in 0.099379 seconds

75 examples, 0 failures

I think it's interesting how the recursive calls back into to_words just kind of fell into place as I went along, without particularly thinking about it. I think if I'd tried to design that up-front it would have involved a lot of head-scratching, and it would have been harder to pick suitable test cases to prove it worked.

Just a little bit of cleaning up before I call it a day – those last three clauses in the case statement look a bit repetitive, so let's see if we can do a bit of refactoring.

Run the specs one last time, to make sure the refactoring didn't break anything:

...........................................................................

Finished in 0.099923 seconds

75 examples, 0 failures

Finished!

On the off-chance that anyone actually read this far, I hope it was at least mildly interesting. I didn't expect to end up with quite such a long post when I started!

Postscript: the 'extra credit' question

This isn't part of the main purpose of the post, because I'm not going to test-drive it, but I thought I might as well include the final part of the problem too:

For an extra challenge, when the strings for the numbers for 1 - 10,000,000,000 are sorted alphabetically, which is the
first odd number in the list?

I'm not sure whether this will complete in a reasonable time, but I'll try a brute force approach – just loop through all the odd numbers and keep track of the one that's earliest, alphabetically speaking. I'm going to start with a much smaller range (up to a million), and put a progress indicator of sorts in so I can see whether it's getting anywhere at all.

Kerrys-G5:~/Dev/RFG kerry$ irb

irb(main):001:0> require 'benchmark'
=> true
irb(main):002:0> puts Benchmark.measure { load 'extra_credit.rb' }
0% complete
1% complete
...
99% complete
eight hundred and eight thousand and eighty-five
115.470000   1.060000 116.530000 (119.292097)

So, two minutes to run the first million – I make that about a fortnight to do ten billion. Time to be a bit more creative.

Thinking about it, eight is obviously the earliest number in the alphabet, and five the earliest odd number, so whatever the answer is, it's going to end in a five, with all the other digits being either zero or eight.

irb(main):003:0> puts Benchmark.measure { load 'extra_credit.rb' }
eight billion and eighty-five
  3.110000   0.030000   3.140000 (  3.149860)

So, if my logic makes sense, the answer is 8,000,000,085. And three seconds is a bit kinder to my CPU than a fortnight!

Final files

• to_words.rb
• to_words_spec.rb
• extra_credit.rb

Wednesday night saw the end-of-year BT Agile Awards dinner, with all the recipients of the various quarterly awards gathering at the Royal Horseguards Hotel to eat, drink, and find out who'd won the overall team and individual awards for the year. It was a good night, made even better by the fact that we won the team award! Our prize is that we're off to the Agile 2007 conference in Washington DC in August.

Congratulations also to Gregg Wyburn for winning the individual award, and to our current colleagues from the .NET SDK team, who picked up their quarter three award for best application of the BT agile values.

More photos from the night on Flickr (see also photos tagged with btagileawards – hopefully some more people will post and tag photos, but BT's webfilter blocking Flickr doesn't help).

:-)

Imagine you're implementing a customer support system where people can submit a problem report along with their phone number, and you want to have the appropriate person ring them to help resolve their fault. Your system does whatever magic is required to find who that appropriate person is, then uses the Web21C SDK to set up the call:

The ThirdPartyCall constructor on line 12 takes two arguments, callee and caller. When the call is connected using startCall(), the caller's phone (the engineer, in our example) rings first. Once they pick up, the callee's phone starts ringing, and the call between the two is connected as though it had been made directly (although neither party sees the other's caller ID).