6 reasons why the public sector should work in the open that aren’t code re-use

James Darling

22 November 2022

Working in the open has plenty of advantages in its own right to justify it as a default best practice

Working in the open is one of the 10 government design principles, and something that public and third sector clients can do far better than the private sector. But more often than not, the business case for working in the open is made purely on future efficiency savings from potential direct re-use of the work.

While that certainly can be the case, there are other benefits of working in the open that aren’t re-use, and are perhaps more profound. We shouldn’t forget them, or see it as a failure of working in the open if re-use opportunities don’t happen. 

1. Greater transparency

Any work being done for the public good should be as transparent as possible, code included. Not only does working in the open help development teams, it also helps build much lacking trust in our institutions.

A particularly sharp example of this was when the UK government asked its citizens to voluntarily download an app to their phone to help reduce the spread of coronavirus. It was critical that the source code to these apps, along with technical architecture diagrams and backend code were all worked on in the open.

The primary reason for this wasn’t to enable anyone to re-use this work, but to provide information to academics, journalists and concerned citizens about what data the government was collecting, and what it was doing with it. This meant they could recommend that more people volunteer their data and follow the advice that was provided, and helped quash misinformation and conspiracy theories.

2. Discourage siloed teams

The benefits of working in the open to build trust aren’t limited to external stakeholders. Many a failed IT project has been caused by internal teams not working well together. This can happen for many reasons, but is hard to fix if members of those teams aren’t able to share what they’re working on with each other. Working in the open limits the ability of disgruntled teams to gatekeep information from colleagues.

Working in the open is a strong way to build trust among internal teams, and teams that trust each other are able to do better work.

3. Daily efficiencies

When you work in the open, you immediately remove many barriers to people working on a project from getting on with their job. Expensive days aren’t wasted waiting for IT support tickets to be raised to provide access to information that isn’t secret. One team can find out what another team is working on without having to arrange a meeting to ask. Features like access control can just be… not done.

Software development tools like Codacy and BrowserStack offer their services for free if your code is in the open. The saving here for a Civil Service department is far greater than the direct monthly cost being waived. Developers won’t have to wait for a purchase order to be raised, or a department credit card to be found to test out their idea. This saves more of those expensive developer days, and allows innovative ideas to be tested faster than the meeting needed to approve the spending.

4. Enhanced security

Many people find this initially counterintuitive, but working in the open leads to more secure services being developed. In the information security industry, it’s recognised that not being transparent can encourage ‘security through obscurity’. This is where systems are secured by deliberately hiding or concealing the system’s internal design architecture and any flaws, rather than fixing the flaws themselves – something that is strongly discouraged by the National Cyber Security Centre.

When you work in the open, there are more eyes to ensure that security stays tight, and quality stays high. Teams can work together to ensure that each component is as secure as possible. This minimises the risk of vulnerabilities forming. If your work is open from the start of your project this makes it easier to address security concerns as you go along.

5. Team pride and recruitment

Having all of your work publicly accessible can be slightly daunting if you haven’t experienced it before, the imposter syndrome part of the brain can get triggered with that fear that you’ll be “found out”. But that’s perhaps exactly why it’s best to overcome this fear, and realise how empowering it can be to create work that you can share and be proud of, and proud engaged teams again, create better work.

This is a relatively unique selling point that the public and third sector can use in recruiting and retaining talent over the private sector. The ability to share exactly what potential new hires would be working on is a big plus for someone thinking about jumping into a new job within the sector. We certainly lean on it when hiring at dxw.

6. Re-use the learning

Even if the code, designs, words or other materials of a service aren’t explicitly reused, the learning of the teams can be shared and re-used. One team may have explored a particular technical or design path and discovered a major issue that meant they had to turn back and find another solution. However, because they explored this option in the open, other teams within their programme, department or across the public and third sectors can learn what they learned, saving an unknowable amount of time and money in the process.

Summary 

Working in the open doesn’t automatically mean that code will be reusable. There is nearly always additional work to be done to get to that point, and often the need elsewhere for exactly what you built isn’t high enough to justify that work. But I hope I’ve shown that if that’s the case, working in the open has plenty of advantages in its own right to justify it as a default best practice.

Perhaps the biggest example is GOV.UK itself, a very bespoke content management system written to meet the specific needs of this one website. Nobody has successfully reused the entirety of the publishing platform GOV.UK uses and, in this case, we would not recommend that anyone tries.

But I’m confident that GOV.UK would not have been the success it has been if it had not been built in the open, with high levels of trust and learning from its development, like the design principles, being used by many other organisations

This is why dxw prefers to work in the open wherever we can and do the work to help our clients move to this operating model. If you’d like to find out more then please get in touch.