It was a 5am alarm that woke myself, and likely my colleagues, on a saturday morning when most people would be comfortably in the land of nod, or contemplating how best to laze away their saturday. For these tombola developers though, it was a drive down to Bradford to attend DDDNorth – a day long free conference setup and run by the community and supported by some brilliant sponsors. The drive down was uneventful, and we were presented with caffeine and brekky before the talks commenced.

Myself, Michael Tomaras, and Luke Hill were in attendance, and we’ll each relay the talk or talks that were most inspiring to us.

Terry Brown

There were two key talks for me – one, which I’ve heard and read a bit about anyway, was around the Spotify model for scaling agile by Stephen Haunts, and the second was a war story from Nathan Gloyn after 18 months of working on a number of projects where microservices played a part.

Microservices – Nathan Gloyn

We’re on a journey of growth at tombola that is seeing us diversify our software products in order to facilitate growth more readily – and although I’ve studied significantly around architecting, building, and supporting microservices, I thought a talk dedicated to ‘what I’ve learned after a year of building a system’ would be right up my street.

There was a bit of background about microservice patterns (and anti-patterns), and discussions around identification of bounded contexts, fat vs. thin microservices and just some key gotchas – security, service discovery, logging (and logging, and logging, and logging some more).

Some key takeaways:

  • Deployment (deploy small, avoid single repo for multiple services),
  • Identity and Authorisation (get these right up front – don’t attempt to retro fit it, it’ll get inordinately harder),
  • Build based upon need (not because it’s cool),
  • Configuration (strongly consider configuration management – consul/zookeeper/et al),
  • Logging (you can never log too much),
  • Monitoring (ensure you understand the baseline and health of each component, but ensure you are monitoring the system as a whole too),
  • System flow (correlation / session tokens in order to track journeys and requests through various systems is crucial)

None of these new, though distilled well by Nathan and he delivered an effective talk.  The only thing missing from this for me was around the organisational change required to support microservices – a move we’re currently undertaking in terms of a shift away from a more monolithic single deploy application into many more smaller, co-ordinated, API driven services.  Conway’s Law and team structure vs. architecture design within an organisation is of key interest to me, and I think it’d have been nice to see a little more around this in the talk.

Scaling Agile with the Spotify Model – Stephen Haunts

Another useful war story about how Stephen and the team at his previous employer had managed the growth of the organisation via the spotify model which they modified in a rather comic ‘lord of the flies’ motif, with islands (multiple companies) and lookouts (marketing/sales type roles that protected the developers from the external landscape that was very much waterfall / deadline driven).

Some really refreshing pointers during this for me on just how best to empower and inspire the workforce while adapting to the growth and change of the organisation.

Key slide of the day for me though was one presented from a Harvard Business Review article.

This is such an incredible visual metaphor for just how satisfied, engaged, and inspired employees would be within an organisation, and I think this will be the one image that goes up on the wall in the office – definitely something to aspire to.


Michael Tomaras

A lot of very interesting talks throughout the day, two of them already covered from Terry and Luke. The one that caught my eye though was not about any specific technology or any new cloud platform. It was about a much debated but little applied concept: “clean code”.

To summarize, all we need to realize as software engineers is really that last part of the job title. We are engineers. And if we compare the engineering we do in software to that of other professions, there is a large part of the industry that simply does not clear the bar. The fact that our product is ephemeral and nowadays can be deleted and re-deployed in minutes allows for a lot of slacking when it comes to code quality. There is also the fact that there is a huge supply and demand gap for programmers, with many of them moving around jobs every two years or so. Add to that the complex problems, deadlines, shifting specifications and priorities, the onslaught of new tech to play with… So many pathways to code bases that are hard to maintain and evolve.

The solution is simple and has been around for decades: Keep you code clean and build in quality from the start. The basic principle is summarized in the quote “code as if the next developer to pick up your work is a psychopath that knows where you live”. 90% of the time we are the ones that pick up the code we wrote 6 months ago and it is the same really, it feels like someone else wrote it. So it’s all about readability and code modularity.  Ways to achieve those? Clear naming, small methods and classes, no comments, code is covered by tests to allow painless refactoring and each team can come up with many more if we all keep caring about the future developers.

The tools to help us have also been around for a long time: TDD and functional testing, refactoring, applying SOLID principles, code reviews. All of these were re-introduced and covered in the talk with great presentational skills I must admit. Resources for them are abundant on the web if you want to dig further.

So if the problem is known and the tools to fix it already exist, why do we face it? It mostly boils down to the fact that, as with any discipline (hint in the name), it is hard. It takes time, persistence and life long practice to achieve these benefits. And our fast moving tech culture and pain avoiding human brains just prefer to ignore these things and go for the shortcuts. It’s like any skill really (think of your favorite hobby, cooking, cycling, music, any sport). There are no shortcuts. We just set some high standards for ourselves and try our best everyday to get a little bit closer to them.


Luke Hill

Operating on minimal sleep seems to be my staple choice when it comes to attending a conference. Fortunately, DDDNorth was chock full of interesting talks and food for thought. Enough to keep even the weariest awake. Take that 5am starts!

Meta-Programming in C# 101 – How Stuff Works – David Whitney

An entertaining talk from a clearly clever guy. It’s almost embarrassing to admit that I fall into the category of developers that use tools and frameworks available to help me achieve my task but ultimately only really care about the code I’ve developed, ignoring those tools and frameworks, how they work, and the role they play.

David broke down 3 areas into simple hello world-esque examples to illustrate that under the hood the conventions and compositions that make up our everyday environments are much the same. A HTTP handler ala MVC, a DI Container ala Unity and a testing framework ala NUnit all created using reflection and a handful lines of code. Surprisingly, not that far off the same handful of lines. A particular mind blowing wow moment was explaining how these practicalities can be used in the real world. For example, handling registration in an IoC container;



My takeaways from this:

  • We should investigate and understand the tools we use. Don’t be scared. Often code is free to browse. Reflection isn’t black magic voodoo and (A slight aside) just look at the revelations you could uncover.
  • Favour composition and sensible defaults. MVC showed us all how pain free development can be when favouring convention over configuration. Then let’s not abandon that approach and drive it forward where possible. Meta-Programming is how we can achieve this goal.

Everyone has heard the old phrase “Reflection is slow and costly” but in reality this isn’t the case. Reflection is fast enough especially when we are dealing with run once scenarios such as IoC registration. David’s advice is that if it is costly then consider a caching approach in the form of an in memory Dictionary object or similar.

David’s presentation slides can be found here.


A brilliant day of learning, some really useful talks, and a day to get some discussion with peers from the industry – all for the bargain price of £0.00.  Further discussions with peers in other sectors who highlighted that recruitment for them was as difficult as it was for us, no matter how cool or interesting the work is you are doing (by the way, we’re hiring! see our careers site)

Free learning, free food, free chat, free inspiration – what’s not to like?  Thanks DDDNorth.