GOTO Copenhagen

So,  before everything gets pushed out of my head, GOTO Copenhagen.

It was my first conference "alone", in that I didn't have friends and colleagues from LMAX or the London Java Community there with me.  And certainly at the start of the conference, I wasn't the only one who was standing around, hoping someone would talk to me (in all honesty some of the photos above are a little unfair - the schedule was a very nice, simple phone app so most people spent a lot of time playing with their phones).

It actually turned out to be an advantage to be alone, as I met a lot of interesting new people.  I was impressed actually by how local it feels - i.e. many of the speakers and attendees were from Copenhagen or at least Denmark.  I liked this, because the alternative is that the conference feels like lots of the usual suspects travelling from place to place, doing the same thing and not really giving much to the city it's hosted in or getting much out of the location.

There was a bit of noise on Twitter, although not as much as at larger conferences.  Actually I think that meant that those who were on Twitter were awesome at connecting up in real life, so I met a bunch of new people who'd originally seen me or spoken to me on Twitter.

War Stories; Coding with the Stars; Coding Using the Disruptor

My sessions were a bit of a mixed bag.  I presented my war story on tracking down a performance problem in IE7, but the most interesting thing about this session was seeing the other two speakers' war stories.  At the end of ten minutes of me talking extremely quickly at the audience, I had no questions - so either my explanation was crystal clear, or I blasted the audience into submission with my caffeine-fuelled nervous energy.  I'm guessing no-one wanted to ask "Can you repeat all that please?".

On Wednesday I paired with a member of the audience on a coding kata - I was really hoping to show TDD (old-school, not TDD as if you mean it), a bit of how to pair (i.e. how you communicate during pairing and why it's dead valuable), and some attempt at showing how you think about your design in a vaguely Domain Driven way.  Although I covered all those areas, I think an hour was barely enough to do one of them justice - I think the tension between showing those three things meant I didn't demo any of them particularly thoroughly or well.  Still, the most interesting thing there was comparing my session with Steve Freeman's, which was directly after - same kata, same language, and totally different approach.  What I hope people got out of this was that there is no One Way to Rule Them All.  

Also, Java is not a good language for getting results in an hour.  Sadly.

My main event was my Disruptor presentation using car assembly as an analogy, which readers of the blog may already have seen in one of its previous incarnations.  At least this time i didn't get a red unsmily face on my feedback like I did at QCon London (whoever you are, tell me what you didn't like!!)

Concurrent Programming Using The Disruptor - Copenhagen

Keynotes - they always force you to learn something new

The keynote on Dart was interesting, I started off feeling very sneery about some shiny new language from Google, but I ended up wondering if we could us it anywhere within LMAX - it's got curly braces and OO, but it's Javascripty.  In a good way (I think).

I took a lot out of Don Reinertsen's keynote and his session "The Tactical and Strategic Art of Economic Models".  Maybe it's just my OCD, but I really like the idea of having actual numbers to allow you to make decisions - understanding the cost of various options as well as the potential gains allows us to make much more informed decisions.  In fact, he points out these numbers don't have to be monetary, but having some uniform way to compare relative costs and benefits of taking certain paths is enough.  Even with average (i.e. not terrible) intuition the range of opinions on the cost of something is 50:1 - that's a big range.  And different people will make different choices based on what they think those costs are.  Michael T. Nygard's DevOps talk also uses numbers on cost to make decisions on whether to actually fix a defect or not.

Rich Hickey's keynote also gave some food for thought.  The main thing I took out of it is that "facts" only have context when associated with a time.  This makes total sense to me, and ties in nicely with some of the stuff we do at LMAX - for example, although it's not specifically time-based, the Disruptor sequence numbers make it clear what's the most recent event, and ensures ordering and repeatability.   It also ties in with some of the stuff in Dave's Continuous Delivery book (sorry Jez, everyone else except LMAX call it Jez's book) - everything, including your configuration, needs to be in source control or some other managed repository, this way you can always get repeatable builds, because its not just the code that impacts the way your system behaves, it's your configuration, your dependencies, so on and so forth.  Having everything trackable by time or revision numbers or something to tie it all together to allow you to get a revision from a specific time makes your releases more repeatable, and makes it easier for you to do things like track down defects on a specific build in production.

Speaking of Continuous Delivery...

There was a lot of good stuff at GOTO around this.  Dave's book was referenced on more than one occasion.  I don't know if it's because that's a conference with quite a heavy lean towards agile, but it seems that getting stuff predictably and regularly into production, and not just being able to compile it and run the tests, is becoming not just an acceptable thing for teams to strive for, but a desirable one.  It's definitely not an easy journey.  But it gives you all the great agile benefits like: fast feedback (from regular releases); decreased waste/inventory (as code is deployed to production as quickly as possible); decreased risk from both of the above things.  

On top of that, it could be argued that by striving for continuous delivery you're driving your design in a nice direction: modularisation, reduced coupling (e.g. if you want to make it possible to deploy individual components), separation of concerns (e.g. feature switches forces you to not have functionality tangled up in your code).  And then there are advantages to the organisation, as in order to create a smooth pipeline from the developer's machine to production, your developers will need to understand more about the environments the system is going to be running on, especially if they're writing/configuring tools to automate releasing.  They get particularly good at this if they're the ones getting the phone calls at evenings and weekends when the release goes wrong...

DevOps

This moves nicely into the DevOps side of things.  It was particular interesting to hear Jeffrey Fredrick from TIM Group talk about the challenges they faced in moving from using managed hosting to an in-house infrastructure team.  It sounds like they've faced very similar issues to those LMAXare working on right now, and I'm very much looking forward to meeting up with Jeffrey back in London so we can exchange ideas.  It's so rare to find anyone with very similar problems to you no matter what your technology or industry is, and it'll be dead interesting to swap stories.

In Conclusion
I think GOTO Copenhagen is the first conference where I spent all the time in sessions - I didn't have gaps in the schedule, and on the whole I got something from all the sessions I went to.  I often feel like I won't have much to take back to work with me when I see new technologies that we don't need to use or people espousing TDD and pair programming, but these sessions, and the keynotes, all gave me something to think about.

Other themes I haven't really mentioned were the same sorts of things I heard at QCon London - e.g. there's always more than one way to do something, and sometimes it's enough to be simply Good Enough.

GOTO was a relatively intimate conference, with a limited number of attendees and relatively small rooms, so it felt easy to talk to new people and by the end of three days I saw familiar faces to smile at wherever I looked.

I'm looking forward to Amsterdam now, although my brain is already full and I'm not sure how much more I can fit in there!