I spent most of this week in Norway at NDC Oslo. It was fun. I met some cool people. I saw some fun talks. I learned some interesting things.

To avoid writing a very long review I thought I would write about two simple concepts that make a lot of sense to me. In my opinion, everyone responsible for delivering software should spend a few moments thinking about these:

Coffee break builds

Richard Campbell (@RichCampbell) of .NET Rocks! did a session on DevOps. He was very funny, reminding everyone that you cannot simply buy “one DevOps” to make your problems go away. DevOps is a mindset and if we aren’t careful it will become a word like Agile – often overused and rarely understood by those who use it.

My favourite idea from his talk was the concept of coffee break builds. The point is that context switching is horrible for developers. When they attack a new problem, let’s call it Foo, they need an hour just to understand it properly before they can actually do any useful work. A few hours later they’ll make a commit and get a coffee. This coffee is a ritual, but what happens when the developer returns is critical:

Scenario A

The build is not finished… so the developer starts working out how to tackle the next piece of work: Bar. They spend an hour getting into it – and forgetting about Foo – until they get Foo’s failure report from the CI server. Now comes the context switch. Every ounce of brain juice the developer has put into Bar (which is now a total write-off of course) has caused them to forget details about Foo. Not only has Bar been completely wasted, but now it will take more time to fix Foo.

Scenario B

The developer gets back from their coffee and is greeted by the Foo error report. They don’t even start working on Bar. Instead they fix the bug in Foo quickly because their head is still in the zone.

Be aware of the golden coffee break time. If your builds fall within this short time-frame you are in a good place. If your builds take too long – be prepared to context switch.

If you would like to watch the whole session you can do so here: http://vimeo.com/97337256

The bus factor

Roy Osherove (@RoyOsherove) did my favourite talk of the conference. How many software talks have you been to that end with a live song? #isTDDdead?

Apart from the wonderful finale, Roy taught me some really interesting things about what he calls ‘beautiful builds’. Snapshot dependencies are well worth a look if you use a half decent CI system. However, what I thought I would write about is the bus factor. Apparently the bus factor is already reasonably well known (a dozen or so people in the room knew about it already) but since most of his audience didn’t, here goes:

How many people would need to be hit by a bus tomorrow before you would be left with no-one with the skills or knowledge to deploy new code to production? This is your bus factor. If you have a bottle-neck where a small number of people act as gatekeepers (intentionally or not) because they are the only people with the skills, knowledge or authority to make the necessary changes you should be concerned. If your bus factor can be counted on one hand, and (for example) those people ever travel in the same car, perhaps you should think about what you would do if, with no warning, that car was hit by a bus. (Or they hand in their notice).

I’m not going to beat the way Roy signed off – so just watch the video on vimeo and fast forward to the end (although I encourage you to watch the whole talk if you have the time): http://vimeo.com/97516289