Basic Law-Making For Legislative Computer Systems – Part 5
Blog by Scottish Government, Research Fellow, Gordon Guthrie.
Gordon is a Research Fellow at the Scottish Government under the First Minister’s Digital Fellowship Programme. All opinions in this blog are his own and they do not represent Scottish Government policy.
This is the last of five articles outlining the research of the Blus project – Basic Law-Making For Legislative Computer Systems. Read the first here – it outlines the problems of connecting slow legislative iteration to fast digital development processes and the second here – it is about building a Frankenstein Bill that shows how legislation can accidentally or deliberately slow down development. The third looks at pattern books that describe what decisions various technical teams need to make, and what needs to be decided before they can make, and how their work is subject to scrutiny. The fourth blog post looks at what we mean by a legislative architecture – the thing we are trying to build – and why it matters.
Part 5 – Testing The Proposals
So we have systematically rethought how we build state computer systems – but it is important to remember that the context that leads to them includes important actors who are not in the government world. The voters want things, their desires are mediated by the press and think tanks and political parties – things happen in context.
The process outlined in the previous articles identifies tasks that the civil service need to do to get better computer systems: faster iteration, catch’n’kill of errors quicker, being more responsive.
But the other task – of looking seriously at each technical trade and saying how do we get appropriate and constitutional oversight of this work? is equally critical.
Without doing the work, it is not possible to make definitive statements about what new oversight structures might be required – but we can make an educated guess.
There are 2 different routes for bills going through parliament and almost all government activities depend on both of them.
The first route, the default route, is the bill path for normal law – laws that grant the power to do something, that prohibit the citizen from doing something else.
The second route – the money route – is about giving the government the hard cash required to do it – raising taxes, allocating income to this department or that programme – monitoring and auditing how it is spent.
There is a saying in tech that data ages like wine and code ages like fish – in more refined terms we can think of data as a asset and code a liability.
This would suggest that elements of the supervision process of digital systems would require parliamentary paths more akin to the money path than the plain law path.
This metaphor can be overstretched. Money is a lump, my £30 cash, your £300 credit card payment and her £3,000 BACS transfer become as one in HMRCs bank account. Data as an asset remains discrete tho, more like property than cash.
So our testing regime must not just cover the government – ministers and civil servants – it needs to involve parliamentarians and the parliamentary corporate body and the wider political class that supports them – think tanks and parties and opinion formers and wider civic society.
The proposed testing process is to run the end to end process as a table exercise – get participants from the parliamentary opposition and the media, as well as ministers, and civil servants in all their glory – policy wonks and parliamentary counsel, service designers and business analysts, software architects and data mavens, operational and reporting staff.
Testing the proposals holistically serves two purposes. First up is to identify errors and omissions in the proposals, iron out flaws and defects. But the second is to build confidence across the piece that the work is worthwhile and constitutional.
Gordon Guthrie is a Research Fellow at the Scottish Government under the First Minister’s Digital Fellowship Programme. You can follow his work in more detail and get invitations to participate in the research on his SubStack.