GitHub Satellite Conference Amsterdam 11 May 2016

GitHub Satellite was a one-day conference in Amsterdam, primarily aimed at developers.

There was no focus on any specific technology since GitHub is just a platform, but instead a focus on the workflows of software development.

There was a Develop track and a Discover track. I had intended to attend the Develop track, but ended up on the Discover track, which turned out to be a good choice.

Opening keynote - Chris Wanstrath, Co-founder and CEO GitHub

GitHub was founded in the USA but is now growing much faster in Europe, with 21% increase in traffic and 100% increase in signups every year. They have more anonymous users than logged in users. This growth is accredited to the growth of the open source community, eg. some large projects such as Linux, MySQL and jQuery.

Some big companies that are traditionally closed source are now embracing open source, and even putting others to shame in the way that they manage the open source projects, eg Apple with Swift and Microsoft with .Net and ASP.

Open source is not just about putting source online, it’s about the way you run the project. It’s a way to work with other people in a community. It’s more about the developer than the code.

He talked about the way some traditionally slow organizations are adopting open source, for example governments, and specifically the UK government with the alphagov/whitehall project which makes it easy for the government to surface data to a website. The people that work there are not experts at making websites, but this project can make them experts, or make it so that they don’t need to be experts.

He then continued with a few topics on the theme of GitHub catering to their own workflow, ie dogfooding :

Finally a few announcements :

Hubot - Brent Beer, GitHub

I must admit I don’t yet understand the power of Hubot, but the people at GitHub swear by it. It allows you to perform tedious and repetitive tasks with a simple command.

Social coding at SAP - Thomas Jansen, SAP

He is a Product Owner who was given the task two years ago to improve the developer experience at SAP. He has given more responsibility to development teams. Not just developing, but also maintaining deployments.

They moved to GitHub because it’s perfect for collaboration and working with open source. They met with initial management resistance, which can be a good sign because it means you’re really trying to change something.

They coined the “satellite” name, meaning tools that are tightly integrated but lightly coupled.

They developed a logical sequence of satellites as they adopted the GitHub workflow across the company :

Now SAP has 9000 GitHub users across multiple disciplines. They created a bootstrap page for new users to document how to get started, create first PR, etc. They develop some large open source projects, such as TwoGo and Concur platform.

Inspiring innovation - Peter Klenk, IBM

Optimizing for cognitive workflows - Laurent Ploix, Spotify

A vague talk about problems of scaling and matching your development workflow to human characteristics. People are bad at context switching, so your workflow should be optimized to give quick feedback. He was describing a build system that they’re working on which will statistically calculate which tests are most likely to fail based on who committed and what has changed, and then run those tests first and give feedback within seconds. You only need to know relevant information - if something breaks, only need to know the delta, eg which lines of code are not covered by tests that were previously.

Every company is a software company - panel

This was a group of VPs etc of big companies particating in a Q&A session. Software is not their core business, but have inevitably found themselves becoming software companies.

panel

Here are a few takeways :

Small incremental releases - Ron Cohen, Opbeat

I didn’t entirely agree with the point Ron was making, which is that each individual developer should release often and take full responsibility for the release. The idea being that it makes developers accountable if they have to fix their own code if it breaks in production, and that it increases velocity and quality. Maybe it works for a two-developer startup, but I don’t think it works at a larger scale.

He’s also a proponent of feature flags so that code can quickly get into production without necessarily adding the feature immediately.

Where I do agree with him is a quote that he repeated regarding code reviews :

10 lines of code = 10 issues
500 lines of code = “looks fine”

ie it’s better to do code review on smaller pieces of code, which implies doing it more often.

code review

The API flow - Zdenek Nemec, Apiary

A detailed and entertaining talk about the workflow to design and develop a good API.

The wrong way is :

  1. write interface

This makes the API hard to change and scale.

The right way is :

  1. Preparation

Step 2 can easily be prototyped with a mock server, which allows stakeholders to jump quickly to step 5.

His slides and website go into more detail with detailed sub-steps for each step.

It is apparent that building an API is more conceptual work than coding.

Closing keynote

The closing keynote was about social responsiblity and helping people at the bottom of Maslow’s hierarchy of needs.

Maslow’s hierarchy of needs

You can help solve world problems by contributing code instead of money. You can look for issues with the help wanted tag and contribute to your own area of expertise.

There were speakers from two open source projects :

You don’t need to know about cancer research to help them with some JavaScript optimization.

There are many more projects on GitHub’s social impact showcase.