Developing Software for Prisons
This is a writeup of the talk I gave at Frontend North in February 2020
I am making the assumption that most of you have not been to a prison. I don’t mean as a prisoner, but also as a visitor, delivery person or in any kind of professional capacity. Statistically, I am probably correct.
I would like you to imagine a prison. Got it? Now, I would like you to imagine a Victorian prison. Because there’s plenty of those still in active service in the UK. If you are anything like me, the word “prison” fills you with dread and the concept of a Victorian prison is downright terrifying. Hold onto these feelings, they are very important.
What sorts of people may we find in a prison? Prisoners, probably. Yes, definitely prisoners. In fact, in some prisons, on some days, the ratio of prisoners to prison officers is 20:1. But there are other people in there, prison officers, medical staff. Workshop staff.
It’s about these non-prisoner prison dwellers that I’d like you to think for a second. Remember the feelings from a couple of minutes ago? Dread, terror? How do these feelings change when you think about the people who work in prisons? The people whose livelihood is a prison?
I’ve enumerated a few roles in prisons, but I’d like to expand on that so you can better understand who our users are. Prison staff have two main responsibilities, broadly - safety and rehabilitation. Safety covers a few aspects. Their personal safety, that of their colleagues. The safety of the offenders - from each other and also from themselves. Being an offender is not easy. And finally, the safety of the general public, ensuring procedures are followed and offenders are correctly monitored to avoid risk to the wider society. Safety plays a big part in what prison staff need to worry about.
Rehabilitation is the other side of the coin. The main goal of the Prison service is to reduce reoffending. It makes sense if you think about - if time spent in prison did not stop people offending, then is it really doing anything? The biggest factor in reducing reoffending is contact with people. Family visits are crucial. Phone calls are crucial. And time spent talking to prison staff is crucial. Prison staff can find out how an offender is doing from chatting to them, potentially avoiding a problem later on. If they have the trust of the offenders, they can find out gossip about who’s doing what where. And they can chat about the football on Saturday and how the new manager of team X sucks. Offenders are people, and people need social interaction.
There are around 135 establishments in the prison estate. Most policies are estate-wide, but they also leave room for maneuver and interpretation. Each prison’s no. 1 governor (that’s honestly what they’re called) is the ruler of their own castles. As a result every prison does something slightly different. Some prisons do a lot of things very differently. We’re building systems to rule them all. Except when we’re not. If only one prison has a certain issue, we’re probably not going to prioritise it. They’re probably not doing things entirely right. We’ll talk to them and try to retrain them. But possibly, just possibly, there’s a legitimate reason they’re doing something different. Maybe the layout of the prison is unique. Or one of the floors is no longer inhabited. Sometimes, we need to consider these things carefully. While we work with prisons as user units, they actually represent some 100s staff and potentially 1000s offenders. These are not small numbers when you think about the implications of not thoroughly evaluating the risks.
Enabling prison staff to spend as little time as possible in front of computers is our goal. The less time using our systems, the more time they can spend interacting with offenders, the better prisons are at rehabilitating. The title of this talk focuses on software and I’ve been talking a lot about feelings. That is because the main thing you need when building software for prison staff is empathy.
As part of my job I get to visit prisons from time to time. I’ve been to three so far - HMP Moorland, HMP Humber and HMP Leeds. Above everything else, above the jarring feeling of enclosement, the constant locking and unlocking of doors, the shouting, the level of alertness, above all of that, I left with one feeling - the determination to build the best damn software I can for these people because their work is already so incomprehensibly difficult. This determination is shared by everyone I work with. It’s quite a unique thing.
Shall we talk software? Let’s. We build web apps, so let’s talk browsers. Our browser support spans anything between IE8 and latest Chrome/Safari/Firefox. There is some fluctuation around how well some things work, but they work. Our users access our sites through a remote server (this is important later on) and as a rule have poor Internet connection. Page loads of any description are painful. There is no wifi in prisons, except for a couple of pilot sites and we have no mobile usage as mobile devices are still in pilot stages. In summary, desktop machines, every browser, remote server and slow internet. I have never catered for an environment less suited to the modern Web. But that’s just me.
Our tech stack is rather boring so I won’t dwell on it too much. Briefly: there’s an Oracle database somewhere in the nether, there are APIs over it, mostly in Java and Kotlin, and there are mostly stateless applications in Node over those APIs. This does not apply to everything, by a mile, but it’s common. We deploy to a kubernetes cluster using helm. As a full stack engineer I end up touching all of the above, for better or for worse. Have I used all the buzzwords? Did I say microservices? No? Well, them. And React. Our users don’t care about any of this, so we’re going to move on.
We try to avoid technical debt. And we try to avoid spaghetti. These things become a bit more difficult when we can’t necessarily afford to avoid edge cases. We don’t always win.
That’s the broad context. Let’s focus on a concrete example. The picture below is a screenshot of a page from one of our applications. This is the Whereabouts application, aka whereabouts are the offenders at any given time. The page title is the name of the activity location we’re looking at, in this case “Workshop 16 - Joinery”. This is data from our test environment, there is no real offender data on this screenshot, before you go and worry I’m exposing someone’s personal information.
Below the page heading, there is a date picker and a dropdown menu to select period - AM, PM or evening. These are horizontally aligned.
Below them is a link that says “Reload page”. Below that is a green button with text “Print list”. Underneath that there is a dropdown with the label “Order the list”. To the right of the dropdown are 4 pieces of text. The top two represent summary information: number of unique prisoners listed and number of sessions. Below those two are two links - attend all prisoners and all prisoners not required.
Underneath all of this, and really, the meat of the page, is a table with 8 columns - name, location, prison no, Info, Activity, Other activities, Attended and Not attended. The values in the Name column, are the offender name hyperlinked to their profile. The values in the Attended and Not attended columns are radio buttons. The rest is text. If you were to scroll to the bottom of the page there is another Print list green button.
Phew, that was a lot. This is a busy page. Let me give you some context. Most prisoners attend paid activities while in prison. This is good for their rehabilitation as it somewhat imitates life outside. In order to get paid for an activity, an offender needs to be marked with the appropriate attendance record. But before they can even make it to the activity, they need to be released from their cell and escorted to wherever they’re supposed to be. These lists are used by prison staff to unlock the right doors - location in the table, and to escort the right prisoners (name, prison no) to the right activity (activity, other activities). They print the list, because they don’t have other means of taking it on their persons while walking the corridors and unlocking cells.
Staff at the activity locations in turn mark attended or not and provide additional information as needed. The bulk action buttons “attend all” and “not require all” make it possible to tackle a large number of mundane actions at once and then fix the few outliers manually. The number of prisoners and the number of sessions allow for a quick gauge if anyone is missing or if something’s gone wrong. The date and period filters do what they say on the tin.
This page did not always look like this. Over time it has grown. Users have requested more and more information in one place. Slow internet, remember? The less they need to move between pages, the better.
This works. It is live in over 30 prisons and has been estimated to have saved 1000s of hours of staff time. Don’t ask me how they estimated it. Be like me and just believe it. Overall it has been a great success.
I have yet to explain the Reload page link. It doesn’t quite reload the page. It refreshes the state. Because this page is entirely built in React, and because it has grown such that by the time we realised we’d broken basic browser functionality we were too far gone to fix it easily.
And with this we touch on a pain point that is relatively new to us - React, it turns out, is not quite the right technology for our users. And this time they do care. I mentioned earlier that they use a remote desktop to access our sites. The whole client side rendering business does not work as intended. Worse than that, users are getting “Something is making your browser slow” alerts. You can’t do that in a high security high risk environment like a prison. You’re causing stress and concern to people who know enough to worry about such alerts. Using React is actually damaging our users’ experience because of the hardware and software limitations within which they work. We’re working to remove React from our sites. We’re in a halfway house right now - some React, some pure server side, but we’re making progress. This page will probably be our final battle.
How did we know to build it like this though? By talking to our users. We have an almost captive audience and they are engaged. We have ex-prison staff working as part of product teams and user researchers and support staff scouring the country, prodding and testing. And we have a very passionate design team. The development and the design teams are in an almost constant tug-o-war trying to minimise complexity while creating solutions that work for all use cases. It’s a friendly tug-o-war. Systematising how 135 institutions interpret policy is not easy and you can’t always do it. We value healthy push-back and provide as much support as we can.
And we’re agile. We’re almost too agile - this space is not used to rapid change and we’re doing and changing things all the time. This has caused some issues in the past and undoubtedly will in the future. While we do our best to talk to as many people as we can, we inevitably miss someone and then they come back to us with a question or a support request. On a few occasions they’ve come back to us in a panic - suddenly we’re showing something that is a security risk in their establishment, for example. This is a very big deal. It’s why having nimble deployment processes is absolutely crucial. We can revert a change and have that deployed to live in under an hour if need be. Don’t ask how I know the time. We don’t talk about that day. But we can, and we know we can because we have been through it, and that gives us confidence. We still try really hard not to break things, but there’s a certain level of uncertainty in everything we do which we have learned to live with and account for.
With all of this being said, almost every person who works in prisons and has had a chance to use our systems is pretty much in love with them. This may be the most challenging environment for web apps I’ve worked in, but it is also the most overwhelmingly rewarding one. Prison staff are used to being neglected. Nobody likes thinking about prisons, and that extends to them. So when they see someone building something for them, taking their opinions and worries into account as much as possible and really trying? Some of them cry. Some of them leap with joy. Some of them (very few indeed) look at us like we’re crazy and refuse to engage. They don’t trust the web when it doesn’t look complicated as that’s all they know. It’s truly extraordinary what a simple web form can do to people.
To wrap this up, I’d like to bring us back to the title of this talk “Building software for prisons”. The building software bit is fairly standard, as I’ve hopefully shown - there’s some code, it goes through some checks, then it goes into the cloud and all is well. The prisons bit is where the interesting challenges lie. So, how DO we go about building software for prisons? Let’s start by caring. Thank you!