BT Software

Adastral Park code retreat

Code retreat poster

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.


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.

Coffee machine hack

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.

Getting started

First session

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).


Flying fingers

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.

The countdown begins

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.

Basking in the glow

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.

Agile BT

InfoWorld Article on BT and Agile

Some time last year I was interviewed by Tom Hoffman for Infoworld, as part of a piece he was writing on BT’s (ongoing) transition to an agile software development model. Here’s the article:

BT: A case study in agile programming


No Internet and no Software

One of the questions for the panel at Wednesday’s Open Source event at BT Centre concerned the fact that most of the company doesn’t have a connection to the Internet; just proxied web access. Also, installing any software not on a relatively small approved list is forbidden.

“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.”

[tags]policy, internet, open source, doc searls[/tags]

Agile BT

Concurrent design and development – a better spin?

Another day, another argument discussion with a colleague over the common misapprehension that you can have a process with discrete requirements capture, design, development and test phases, yet somehow still claim to be agile. Once again, I tried (with limited success) to explain that you don’t need to do all your designing up front before you start writing code, and that starting to write code almost immediately isn’t ‘hacking’, provided that you are continuously paying attention to good design as you go.

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.

[tags]agile, tdd, bdd[/tags]

Agile BT Ruby Software

A step-by-step BDD example using RSpec

We’ve now got a Ruby focus group at work, and one of the first things to be set up has been a weekly programming exercise [intranet link], in the style of Ruby Quiz. It’s now week two, and the problem is slightly more complex than last week’s gentle FizzBuzz introduction. Here’s the specification:

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!)

Agile BT Enterprise Rants Software

Software/geek symbiosis

Yesterday I was lucky enough to get the chance to attend a talk/workshop on TiddlyWiki, presented by its creator Jeremy Ruston, with quality supporting acts from JP and Doc Searls. Jeremy has just joined BT as Head of Open Source Innovation, which is pretty cool in itself.

One of the comments he made that particularly struck me was to the effect that a piece of software is a living thing, but is parasitic, requiring a ‘geek host’ to live on. Much of the value of software isn’t what it does, but what it can potentially do. Once you separate the software from its geek, it starts to die, because it can no longer adapt to changes in its environment.

I think this is something that we’re losing in the world of corporate IT.

BT General nonsense

Blast from the past

The things you find in server room cupboards!

Agile BT

BT Agile Awards final

The CSAM-n team receiving our trophy

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).

General nonsense Web21C

JohnMac and psd: the real story!

According to Twitter, anyway:

John’s one friend


BT Java Web21C

BT’s Java SDK part two: making phone calls

Yesterday we saw how easy it is to send text messages using the SDK, so now let’s try making a phone call.