This week GDS hosted the second in a series of unconferences we’re organising to better connect the growing community of technologists in government. Building on the success of the recent technical standards camp, this time we were focussed on how we can improve sharing of code and collaboration.
This event was slightly smaller than the previous one (perhaps partly because of a rather early start?) but around 50 technologists from across government gathered at Aviation House eager to work out how to build on the past few years’ momentum around opening up government code.
We followed the same structure, with a group of lightning speakers kicking things off. Rosalie Marshall talked about her recent work on documentation which is a growing theme and will be the subject of its own event this week. Gemma Leigh provided a run-through of the different frontend toolkits and pattern libraries that are available to make it easier for teams to ensure their services adopt a consistent look and feel across GOV.UK, Al Davidson from the Ministry of Justice talked about some of the common concerns people have when adopting each others’ code and the possibility of some standards to improve trust, and we had a presentation from CESG on their emerging set of security design principles.
The attendees then pitched ideas for breakout sessions, quickly filling the nine slots and conversation flowed. As we’d anticipated there was quite a bit of overlap with the standards conversations, and common themes came through clearly: concerns like versioning and documentation, the challenge of understanding what other people are working on, and the importance of mechanisms that build trust were all hot topics.
It was also clear that many attendees are feeling the pressure of working in rapidly changing cultures. The last few years have seen rapid shifts in our thinking around agile, cloud and open source at the same time as concerns about security have heightened. The sessions on security particularly brought this out as attendees talked about communicating how all the entwined changes fit together to non-specialist senior management, as well as about the changing opportunities for security as automated tooling attracts a lot of attention.
There were several active conversations around tooling in general, and on how we make decisions about what should be provided as reusable code and what should be provided as hosted software-as-a-service tools. The latter clearly fits with some of the work the Government as a Platform team have been writing about lately.
Across everything, two themes really stood out:
Visibility - it’s a huge challenge to know what everyone is working on and to find the things relevant to you in amongst so much activity. Events of this sort are a start at addressing that, and we’ll be supplementing them with online discussion, and also developing ideas about providing a single place to find particular reusable code. It’s likely to remain a challenge for a long time to come, though, and we’ll all be continuously looking for examples of good practice elsewhere.
The human factors - making code reusable and supporting it for others can be very time consuming and we’ve yet to develop good models for supporting things in ways that don’t meet our own teams’ immediate needs. That’s particularly apparent in the tricky intermediate phase for an open source project, where it has a growing group of users but hasn’t yet grown a really active community. Where we see value in supporting code used across teams we need to make sure we’re putting the right support structures in place to let people manage the work.
As a team we’re still working out the right next steps to build on the event, but we’ll be doing everything we can to maintain the momentum. If you’re working in government and want to join the conversation, we’re beginning to list the appropriate forums on this blog so take a look there and get involved.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.