Guest blog post by Brigette Metzler
The Better Rules Hack held during Techweek 2018 enabled people from the public, private and non-government sectors to share their expertise and learn about the challenges and opportunities of turning legislation into code to support public service delivery. Brigette Metzler, an Australian Public Servant who participated in the Better Rules Hack, provides her perspective and reflects on quickly building a team with a unified sense of purpose and understanding, and how her team went about designing legislation as code.
It’s my first time in New Zealand, and though this post isn’t about that, place is a good point from which to start. The spirit of the land is almost visceral as you fly in. The mountains are like a giant just settled, laying a craggy body down deep into the sea. Looking down over Wellington from the sky, Wellington is a place that is itself, is accepting the presence of houses and roads only reluctantly. Five days in and I still felt it - the soul of the place is big, and it is strong. Surely it is in the bones and blood of the people who live here, so seemingly confident and sure of their roots.
Why is this important to legislation as code? It is this confidence, this surety of spirit that enables stuff like this, so that’s worth calling out right there. So thank you Wellington, you were a breath of fresh air. And thank you Pia, a woman of spirit and surety and place if ever there was one.
So, spirit was important, and it was what got us there, but I really want to share with you the experience of doing the thing, because that’s why you’re reading this, right?
First up, I want to say that I’m not a coder or a data scientist. So hopefully, this post will be of use to anyone working in government or beyond who wants to grapple with legislation as code and what it feels like to do it, just as a regular human being.
Legislation is one of those things we have that is institutional, that drives our lives, mostly without us feeling it. It is rules with a big R. For the most part, it is logical and it follows almost archaic patterns of expression, where the slightest ‘and’ or ‘or’ can change everything. But we get it, right? If we read it really slowly and tilt our heads to the right and squint?
Hear me out. It follows that if someone has ‘earnings as a self-employed person’, that we understand the legislation is talking about a ‘person’ (not a fish), who is ‘self-employed’ (is their own boss) and has some ‘earnings’ (we probably even hear that word and think things like ‘after tax or before?’).
Before the hackathon, I would have separated out ‘person’, ‘self-employed’ and ‘earnings’ and tried to create a dictionary of terms. I probably would have sat down with a bunch of people to whom these words were important (yep, including self-employed people) and asked them to help me make some definitions of them. Then, I would have made a Uniform Resource Identifier (URI) for the word/s, because I’m that way inclined. (URIs are not some kind of disease you don’t want to talk to your doctor about, they’re a unique identifier that everyone can use when they talk about the same thing, even if they don’t use the same word). Then, I might have tried to model them. I think ‘self-employed’ is probably a kind of a role you can have when you’re working, so I would have said ‘self-employed’ belongs to class ‘employed’.
But doing it was different! What I learned, is that defining, and coding are best done together, side by side. I am thankful I was in a team of people who did know how to code, and they trusted that defining what they put in the code was important.
I think trust is what we built pretty early in the team, as we all knew where we’d come from and therefore how we belonged if that makes sense. Nigel, Allen and Jacob were trusting me on the definitions thing, and I was trusting them on the code thing. So, with that trust, we decided to flip the thing, and do the code before the metadata, like this:
class: sum_of_earnings_during_compensation_period_in_last_52_weeks(Variable):
value_type = float
entity = Person
label = u"Earnings during the period in which the donor was entitled to weekly compensation (as defined in section 6(1) of the Accident Compensation Act 2001)"
definition_period = YEAR
Because I know it will make all those who code happy to know, we didn’t just do the code before the metadata, we actually wrote the test code before we wrote the solution code. It’s all code, but that was a key factor to how we could quickly get to grips with what we needed to do (given we had no idea to start with).
We kept running the failing test, and it would tell us what was wrong now, and we inched towards the solution. Once the solution was working, we could think about the future and what success looked like, across multiple pieces of legislation.
This meant doing some work for the future - doing some work on the definitions. We didn’t do anywhere near as much as we’d like, but we started, and that’s the main thing! We pulled out what needed defining from the code and worked our way backwards. In the example above, ‘sum of earnings during the compensation period in the last 52 weeks’ has a bunch of different things all mashed together. You could define ‘sum’ and ‘earnings’ and ‘compensation’ and ‘period’ and ‘weeks’. But why would we do this if we’ve just turned the legislation into code? It’s all done isn’t it? We’ve rendered it knowable to a computer.
If we want to move beyond our silos, then we need to create a way to search for what’s common, a solid base from which to re-imagine who we want to become. To know ourselves is to be able to grow into something more, and we need that more than legislation as code, or any other thing being done right now.
Lucky my teammates could not only see I was serious about this, but they knew they could work with what I proposed, so as an interim measure, we did this:
Class: earnings_period_in_weeks(Variable):
value_type = int
default_value = 52
entity = Person
label = u"The number of weeks over which earnings have been earned"
reference = "https://github.com/OrganicCoders/openfisca-aotearoa/blob/master/openfisca_aotearoa/definitions/number_of_weeks.md"
definition_period = YEAR
You can see here we have the entity ‘person’, a class ‘earnings period in weeks’ and a reference that resolves to a place where we could store a Uniform Resource Identifier (URI) we randomly (and not to any particular standard) applied. This gave us a space to put the stuff we needed to do, which was connect this thing to a thing we knew had already been defined (‘person’ ‘period’ etc).
Given time, we could do it properly and map the whole thing to a set of defined terms rather than sending people to a decoy URL, and then go through another piece of legislation, and another and another. Judging by the awesome work done by another team at the hackathon, I know we’d get faster and faster, and we might discover some amazing things about the legislation that slips unnoticed through the fabric of our lives. I strongly suspect, like a beautiful woven piece of fabric, that what looks complex and wildly diverse from afar probably holds a warp and a weft we can recognise as the fabric of our lives, holding it all together.
I’m grateful for the chance to experience doing legislation as code, for our fantastic team of Organic Coders and the work we did to use legislation as code as a tool through which we could do something tangibly good for people’s lives. Ultimately, that’s what it is all about.
