Basic Law-Making For Legislative Computer Systems – Part 2
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 second of five articles outlining the research of the BIus 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.
Part 2 – Frankenstein Bill
I am sewing together a Frankenstein Bill from bits of other legislation – an incoherent mis-mash of fragments, clauses ripped, still beating, from different parliaments, from different countries, from different legal traditions, from airts and pairts.
The name of the game is consequences. Law impacts state digital systems and services underpinned by them in two ways: intentionally and accidentally.
Sometimes lawmakers go into a legislative process with a desired system intent – an example would be the creation of the Scottish Social Security system. Ministers and civil servants intended to create new computer systems.
But sometimes the specification of computer systems is unintended. An example would be the very first GP (General Practitioners – personal/community Doctors in the UK) administration systems in the mid-1980s. These primitive systems followed a well trodden pattern. The structure of an existing paper form was transposed into a primitive PC-based database. The person who designed the paper form, designed inter-alia, the database structure – and conjured into existence, again accidently, all the processes and GUI (Graphical User Interface) and rules to manage that data. As it happens, my brother, then a newly minted Doctor and now a Professor of General Practice , did the work.
We know that the Minister didn’t intend to design the computer system when he personally designed the form. How so? Well, Lloyd George last held office in 1922 and died in 1945 just at the dawn of the (still a military secret) computer age. The form that my brother helped computerise was called the Lloyd George form, from its design by him in 1911.
Even when the bill is designed to create digital systems, understanding of the consequences can also be accidental. One of the items in the Frankenstein Bill shows an unintended consequence of the Scottish Social Security Bill – Conway’s Law.
The purpose of the Frankenstein Bill is to be a showcase of consequences, both accidental and intentional, as a training exercise. The technical trades (the code monkeys, the designers, the content polishers, the org-mongers and all) need to communicate our needs better with our customers: the policy wonks, the SPADs (Special Advisors), the Ministers.
Having a Frankenstein Bill, with examples and explanation of the subtle impacts will help us design the training materials.
I am writing, or more properly sewing together, the Frankenstein Bill in a familiar (UK) format of legal text and explanatory notes on GitHub. But I am looking to crowd source examples: from Scotland, other UK jurisdictions, and across the world.
I have seeded it with some curated examples: ranging from Hammurabi’s stele carved in Akkadian cuneiform on basalt, through snippets of Scottish, Westminster and French law. Each snippet is chosen to identify a generalisable impact – they are meant as examples of wider practice.
And that’s where you come in – come show your scars, where your project snared on the barbed wire of primary or secondary legislation.
If you are familiar with GitHub, raise a PR with your contribution – if you are not email me an example at firstname.lastname@example.org
The Frankenstein Bill will be an important resource in the design of the legislative article which I will discuss in the 4th article in this series. But first we need to look at technical pattern book – sets of tasks for each of the digital trades, from data specialists, technical implementers, organisation, service, UX, interaction and content designers. Read about that in part 3 of this series.
You can follow Gordon’s work in more detail and get invitations to participate in the research on his SubStack.