QCon 2015

A couple of weeks ago I had the opportunity to attend QCon London and experience a lot of interesting talks about a surprisingly wide range of topics in the computing / IT industry. This is a quick summary of the overall conference and talks or presentations I enjoyed the most, and what I took away from the conference.

The conference

QCon London 2015 was held in the QE2 Exhibition Centre in Westminster, which although hideous from the outside is actually a pretty decent venue, and very well connected (a 15 minute walk from Charing Cross Station or Victoria Station and only a few minutes away from Westminster and St James Park tube stations.

I attended the Wednesday, Thursday and Friday (the main conference days), each day started bright and early at 8.30am and continued on until at least 5.40pm - or later if you went to any of the evening social events or talks.

To avoid going into George RR Martin levels of description, here are the key points about my general conference experience:

• I thought the keynotes were decent - I'm generally a huge sceptic of keynote talks (they're quite inspirational / motivational, but fall short on content) but the two that I attended were interesting and well presented.
• The exhibition was good, most of the exhibitors were engaging and told me about their companies / products without pushy sales tactics (a notable exception was Atlassian).
• I liked the lunch load-balancing system, giving each attendee one of three coloured stickers which represented the place they were supposed to go for lunch. It actually worked fairly well and kept queues short.
• There was a lot of conference swag and plenty of decent prizes to be won. Ok, sure, this shouldn't be important, but one of my colleagues seems to almost exclusively stock his wardrobe with corporate branded t-shirts, so others might be interested!

A note on videos

One of the things I liked about QCon that sets it apart from many other conferences is that almost every talk is recorded, edited and published online as a good quality video stream - usually only a few hours later. This was great, as there were quite a few slots where I had to choose between 2 or 3 presentations that I wanted to see.

At the moment, these video streams are for conference attendees only, but in around 6 months time they should be made public. I'll update this post to link directly to the videos at that point. In the mean time, I have a few "shares" left - so if anyone is desperate to see any of these, let me know in the comments and I'll try to arrange it.

Update 24/06/2015: The videos are now public and I've added a link below each summary.

Treat your Code as a Crime Scene

This was the first talk that I went to (not counting the initial keynote and introduction), and what a way to kick off the conference. A topic that I'm intimately familiar with and enjoy thinking about, very reminiscent of some of the ideas that I covered in my blog post about Software Archaeology.

Starting off with brief a discussion about metrics, and how to measure complexity of code in general, Adam Tornhill launched straight into the meat of the topics that I like to explore - how to identify complex, brittle or commonly edited pieces of code.

True to the title of his talk, Adam quickly introduced the idea of Geographical Profiling - a criminal investigative method used to help narrow down the likely area where a serial offender may live or work, based on the location where the related crimes were committed. I very much enjoy the idea that bugs are essentially "code crimes" and that we may be able to leverage data in such a way as to zero-in on troublesome areas in this way.

Of course, to do this we can't just look at the code in its current state, we must draw upon revision history and statistics from version control, and then analyse and present this data in a useful manner. Adam introduced a number of potential visualisations, including the intriguing Code City, where lines of code are represented in the height of the generated buildings.

Adam goes on to suggest that the code quality of an individual source file is inversely related to the number of programmers that have worked on a source file (the theory being that more people get involved in troublesome areas as they have to be touched more often), and that while there are lots of measures of complexity, the number of lines is in most cases a pretty good indicator.

The final suggestion from Adam was that in addition to analysing code in this way, it would be interesting to experiment with more proactive warnings or monitoring - letting developers know when they're about to work on particularly complex or commonly edited code (i.e. here be dragons). He also suggested that version control tools could implement Amazon-style recommendations; "other developers that worked on file A also worked on file B", which sounds like a great idea.

One of the main things I took away from this presentation is that our reporting and analysis tool set around version control is very primitive and there are lots of amazing things we could do that could harness that data set to yield real day-to-day benefits for developers and customers.

Unfortunately, this is one of the few talks that will not be made available as a video, but I would recommend reading Adam's blog and I will certainly be checking out his book when it's released.

Update 17/03/2015: Adam very kindly sent me an email to say that the video is available, it's only the slides that will not be published.

Video link: http://www.infoq.com/presentations/code-bugs-legacy-pitfalls

Delivering GOV.UK: DevOps for the nation

I already know a fair bit about the Government Digital Service and GOV.UK as most of the clients I deal with are Government bodies. For those that don't know, GDS are essentially a software development branch of the Cabinet Office, promoting their agenda of "Digital by Default" by laying out expected standards that Government systems should meet, and by building exemplar projects to provide examples of best-practise.

GOV.UK is the focal point of the GDS effort - a central website for all interaction between the Government and its customers (members of the public and industry). This talk by Anna Shipman offered some insight into how GOV.UK is developed and changes deployed.

She covered the usual DevOps mantras, culture, trust, agility and so on, but that was all fairly standard or expected content. The things about the talk that I found interesting were:

1. There is a well-maintained operations manual to help people support the live services, so if someone is on-call and doesn't know a particular area that well, they can draw on a wealth of information - or write that information for the next person once the problem has been investigated and resolved. This is clearly a good idea that all companies should really have in place.

2. Deployment to production is managed by the requirement to have custody of a stuffed toy badger in order to deploy. I don't know if it's an intentional spoof of the Government's policy on culling badgers, but I couldn't help but chuckle slightly at the irony. It seems a little silly, but I can see the merit, especially as…

3. Developers can deploy from their own laptops - a stark contrast to the usual Government process of using dedicated, locked-down machines with direct VPN access to data centres.

A cited example of the benefits of letting developers access production from their own laptops, as opposed to a locked-down secure laptop, was that when the Heartbleed bug in OpenSSL became public knowledge, developers (not even the ones on-call) were able to patch the live servers during the course of the night, from home.

Although developers patching a vulnerability from home provides a compelling narrative, I can't help but find the idea of uncontrolled security patching completely reckless. The risks of server outage and/or improper patching being performed by well-meaning but tired developers in the middle of the night shouldn't really be trivialised, let alone cited as an example of a successful process - especially as there are many better arguments that could be used. Also, I kind of want to know where the badger was while all of this was going on!

Overall the talk was interesting and informative and I enjoyed seeing perhaps a bit of a different perspective than what most are used to.

Video link: http://www.infoq.com/presentations/gov-uk-devops

Small is Beautiful

In-line with the title of Kevlin Henney's talk, I'll keep my summary short - it was all about a topic close to my heart, how smaller code is more maintainable. The name of the talk and many of the concepts explored are from the book Small is Beautiful by E. F. Schumacher, which he quotes from and draws comparisons with throughout. I personally thought the idea of examining software development from the perspective of economics was both novel and intriguing.

During the talk, Kevlin came out with some amazing phrases, a couple of which I'll quickly quote here to give you a flavour of his style: - "Alcohol is a solution, it dissolves many things" - "A software system is executable fiction. You are making stuff up and you get paid for it."

The consistently reinforced message delivered is that we should challenge ourselves to produce better code - more modular, smaller code that is easier to maintain. Kevlin explores the merits of this, and also the reasons why we don't necessarily do it, including a key idea that we don't challenge ourselves or push ourselves hard enough to reach such goals.

Towards the end of the talk, Kevlin covers the idea that our code is often made larger because of workarounds for problems that may no longer exist - code changes introduced to work around memory limits that existed 10 years ago, but no longer, bug fixes for edge-cases that are no longer required and so-on. These things all pollute our code-base with size and complexity but nobody actively goes looking to remove them to keep things simple for the requirements of today. He concludes with an idea that he coined a few years ago about "Decremental Development", the idea of reducing software down to only the parts that are necessary.

Although Kevlin comes at this from the angle of code complexity, I have been thinking quite a lot about this from the avenue of performance, i.e. where an introduced workaround solves a problem, but at significant cost, and then may never be removed even if the original problem is subsequently solved. I'll be writing a blog post about that topic at some point in the future.

All in all, I thought this was a very inspiring talk, filled with common sense and compelling narrative. For my money, one of the best of the conference.

Video link: http://www.infoq.com/presentations/small-large-systems

Back to the Future: what ever happened to being eXtreme?

Rachel Davies kicked off the second day's "Evolving Agile" track with a brilliant overview of Extreme Programming and practises that have dropped out of common use in recent years.

Starting out with a completely spot-on observation that "extreme" is a really poor word to match with the idea of programming, and that it may even be the reason people talk less about extreme programming these days, Rachel goes on to introduce (or reintroduce) the idea that the practise is about finding things that you're good at and doing them more - taking things to their logical extreme.

Rachel then introduces what she termed "Agile Sadness", that people equate "extreme programming" with a watered down form of what most people would deem agile best practises, i.e. some parts of the build are automated, there are a few automated tests, programmers paired once or twice, maybe. This is not the "extreme programming" that she recognises and works with on a daily basis, but a reality for many programmers in what is commonly a very pseudo-agile world.

What followed was a quick whirlwind history of Rachel's experience with XP, some of the best practises (such as retrospectives) and why they are beneficial.

Rachel moved on to describe how her team works at Unruly, which I found interesting, with some aspects of it quite familiar from my not-too-distant past, and some aspects something that I've never really experienced and would be more than willing to try out. Some of the more common / usual things that they do include:

• Developers monitoring and supporting production systems.
• Acting as business analysts, spending time with the business users.
• Standups and retrospectives.
• Paired programming - while not unusual in and of itself - is the norm, it is apparently rare for anyone at Unruly to be programming on their own.

Some of the things I found really fascinating included:

• Developers decide what to work on next - they do research with the business and work out shared priorities, so that nobody spends time working on features that provide no business value.
• Mobbing - basically the same idea as paired programming but with more people involved, so a group sit around a large TV and observe and discuss while one person writes code - swapping around every 10 minutes.
• Building 20% learning time into the working velocity - to keep fresh ideas coming in and motivation high.
• Using a developer-on-support rota essentially as a human distraction shield, so the other developers can get on without interruption.
• It turns out that developers at Unruly only write code about 40% of the time, due to the 20% learning time and other responsibilities (research, monitoring, support, etc). As Rachel points out, this is fine.

I thought Rachel painted the working environment at Unruly as both effective and enjoyable and I think we could all learn a few lessons from how they do things. I'm not suggesting that we adopt all of their practises, but in the spirit of the talk and XP, we should find out which ones work and do them continuously.

Video link: http://www.infoq.com/presentations/xp-evolution

Why BDD can save agile (Matt Wynne)

Last but not least, I'd like to mention Matt Wynne's talk and insight into BDD (Behaviour Driven Development) and how companies often misunderstand what it means to "be agile", just paying lip service to the ideals by using techniques from scrum.

Matt gets quickly to the point, identifying the common problems faced by software development teams:

• Predictability - is the team delivering on time?
• Communication - are they working together well as a team (including all disciplines, i.e. testers, product owners, developers)?
• Quality - strongly related to the two above - it causes frustration for the team if there are lots of problems or defects.

He goes on to explain that it's possible to counteract these by addressing them directly:

• Small pieces (solve predictability by breaking things up properly).
• Collaboration (communicate and really work with each other)
• Technical discipline (TDD, refactoring)

Matt expands on each of these, explaining that BDD practises can help facilitate communication between the individuals involved in a project and helping them work towards these goals. He explains that small, concrete examples of how a system should work can become the "single source of truth" for that information - everyone can refer to this common resource of stories to understand the software.

Explaining why TDD (Test Driven Development) is important, Matt says that automated tests are essentially warning lights, and whether you add them before or after writing code, you guard against the risk of regression later on when making changes. The crucial thing that this enables you to do is refactoring - which he says is a horrible technical term that means that product owners and customers don't necessarily think it is a necessary practise, when in fact they should be interested as it is a key part of maintaining the health of their software.

Pushing the point further, Matt used a great metaphor, asking everyone to imagine they work in a restaurant instead of software development; the developers work in the kitchen producing food. Does the kitchen look professional, tidy and clean, or like a horrible, dirty student kitchen? If your kitchen is dirty and cluttered, your chefs will produce unhygienic food and will trip over all the time. As a metaphor I think this is great, and a clear, easy way to explain the problem of messy code to stakeholders.

Matt concludes by saying that you can't just cheat on agile, you have to demand excellent communication, have excellent collaboration and have excellent code; this is where the agility comes from in agile.

I thought this was a great summary of the problems faced by many pseudo-agile teams and contained some simple ideas that most people can easily introduce into their workplace.

Video link: http://www.infoq.com/presentations/bdd-agile-patterns

What I took away from QCon 2015

It seems like a lot of teams are struggling to properly implement agile practises, and I'm glad to see that I'm not the only one who has experienced some of these problems over the last few years. I got a lot of food for thought, but what I found great about QCon was the focus not only on ideas, but how to sell them and the real business benefits behind these improvements in working practises.

I very much look forward to attending again next year.