Basic Law-Making For Legislative Computer Systems – Part 3
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 third 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 and the second here – it is about building a Frankenstein Bill that shows how legislation can accidentally or deliberately slow down development.
Part 3 – Technical Pattern Books
If we are to make the production of digital systems explicit we need to every participant to be able to understand their role – and critically that means making the technical decisions visible and comprehensible.
Parliamentarians, Ministers, SPADs and policy experts don’t need to know what the various technical trades do at a detailed level, they don’t need to be experts in software architecture, qualitative studies, user engagement or information architecture. But they do need to know what decisions the specialists are making and when – and critically what those specialists need to know before they can start their job.
Imagine we had an implicit process for building a house:
- Alice buys bricks
- Bob buys carpets
- Charlie buys land
- David paints rooms
- Eddie does the electrics
You move in the house and there is paint all over the carpet. You ask David, he says “I just paint rooms, they tell me, I paint”. You ask Bob, “mate, I put the carpet down when they tell me”. You go to plug the cooker in and plumb in the washing machine and there are no facilities in the kitchen.
In an explicit process:
- Alice buys bricks to build houses
- Bob buys carpets for living rooms and bedrooms
- Charlie buys land for houses and gardens
- David paints kitchens, bathrooms, bedrooms and halls
- Eddie wires bathrooms and kitchens and bedrooms
So the purpose of building technical pattern books across the delivery trades in government is to capture all the common tasks and their pre-conditions.
David paints the rooms, but he needs Eddie the spark to have finished wiring them and Pete the plasterer to have done his job.
And the second reason for the pattern books is to identify the oversight. Eddie the electrician is a time-served man with a ticket, Gordon the gas is a registered fitter. They screw up – they can be disbarred. And the gaffer goes round and checks their work on the day.
So it is with civil servants. What does the audit-commission-for-technical-delivery look like? Well if it has gaps, the pattern books will tell us.
The pattern books will be written by the experts – people who work in the technical streams. I am organising workshops where we will systematically build a picture of what needs to be decided and at what scale.
(If you wish to participate in the work of developing the pattern books – subscribe to my SubStack (link at foot of this article) to receive invitations).
The legislative engine has 4 speeds, so let us imagine technical engines that also have 4 speeds:
What we wish to achieve
By breaking down all our work streams in this manner we will be in a position to move onto designing a legislative architecture – which is the subject of part 4 of this series.
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.