The 10th and last Government Digital Service design principle is ‘Make things open, it makes things better’. I love that it’s there, written down and published on GOV.UK for us to point at in times of need.
It’s that principle that has allowed individuals and teams to create and then share many of the toolkits and and pattern libraries I use on a daily basis, in my role as a senior front-end developer at DWP.
The GOV.UK Prototyping kit and GOV.UK Elements are 2 examples of excellent open tools that designers and front-end developers benefit from greatly. They speed up our work, keep it consistent and allow us to focus on the problems we’re trying to solve.
It takes effort to be open and better
At face value that important principle could be taken to mean, ‘simply making it open, will make it better’. But the reality is not quite so passive.
There is effort and complexity involved in making work open. And in managing the process of making it better.
It’s easy to forget that behind a lot of open-source projects are individual developers. Often working in their own time to improve something they’re passionate about in a way that will benefit others. It’s important that teams are aware of this and can support it.
And contributing to open-source code can be intimidating. Many of us don’t feel comfortable opening ourselves up to critique, don’t want to bother already busy people or perhaps don’t know how to take part
This post highlights the contribution of front-end developers working across government and as an example focuses on some of the contributions made by a developer at DWP Digital.
In the trenches
I often describe front-end developers working on government services as being ‘in the trenches’. What I mean is that they're working under pressure to get things done that will help delivery of real ‘live’ services.
But their contribution doesn’t stop there. It's more accurate to characterise most government delivery teams as ‘coding in the open’ rather than truly offering open-source software. This is often because teams don't yet have the resource to actively support and maintain code beyond their own needs.
Many interaction designers and front-end developers in government recognise this fact and yet take responsibility to ‘pay it forward’ whenever they can.
Day-to-day they might do this by
- documenting and reporting a bug to the original team, developer or software engineer, to let them know their code has a problem
- fixing the bug, if they can, and contributing it back to the original source code
- updating code dependencies, bringing the latest fixes and feature changes, and then pushing that updated code back ‘upstream’ to the original source
You might be doing most of these things for your team anyway, so why not take that extra time to help the original authors and those that follow?
It's about placing importance not just on making your work open, but on helping to make the work of others better. Just as all of our jobs delivering government services have been made easier by other people’s code being open and available to us in the first place.
Making good choices
Responsible designers and developers will try to make considered choices about the code they choose to write. Before writing bespoke code, it’s important to check to see if the problem has already been solved elsewhere.
It's not always the case that we can reuse what has been done before, but we should start by seeing if we can. If we're lucky we might find somebody has already done the job for us.
If what exists doesn't meet our needs, can we adapt it? If we can, then we should do the work and push it back to the community. These choices are what saves thousands of hours of people's time.
What organisations can do to help
Organisations and managers need to be aware that this work is happening. And they need to appreciate the value of it.
The work that individuals do up front can save a huge amount of time and effort down the line.
Three things managers can do are:
- understand how much time it can take for people to feed back changes into the community
- make sure that these people are supported and can take credit for their work
- try to formalise this work - make it part of people’s objectives and make sure resource is available for them to do this
An example: one developer's impact
Here’s an example of the work done by a developer who worked with us at DWP Digital last year, Colin Rotherham.
You can see how he approaches raising ‘issues’ and then works with people to get them resolved. All of which is done while delivering in the trenches.
On that note, I think his team, particularly the product owners he worked with, need recognition for allowing Colin to set aside some time to work on improving the bigger picture. He did some of this in his own time, but he was lucky to get the backing of his team as well.
Here are some examples of how one developer can make things better. Colin:
- added support for CommonJS module-loading (Browserify, Webpack etc) to the GOV.UK front-end toolkit, allowing us to use modern developer tooling
- added support for Google Analytics overrides to GOV.UK frontend of toolkit, allowing the analytics code to be extended and configured to meet service needs
- added support for (more) Google Analytics overrides to allow links to be tracked with additional options
- opened a discussion on [role=button] for GOV.UK links, which resulted in user experience needs eventually winning over code semantics
- fixed unhandled JavaScript error in Home Office autocomplete affecting live government services
- moved Home Office autocomplete upstream to a newer fork, bringing 2 years of bug fixes and feature changes
- contributed Home Office accessibility fixes back upstream, which are now downloaded more than 3,000 times every month
It is very satisfying to know that you've solved a problem for others, you've got their back and they've got yours.
So let's continue to help each other by allowing more designers and developers the space and time to contribute back to the community. A problem shared is a problem way more than halved.
Follow Paul on Twitter, and don’t forget to sign up for email alerts.
