Until last week, calculating the suggested sentence for someone convicted of a crime under the Massachusetts Sentencing Guidelines was a time-consuming process involving multiple cross-referenced documents, formal logic, and some basic arithmetic. Now, thanks to an ABA Journal sponsored hackathon, there’s an app for that (Due Processr). The app even helps determine if someone is eligible for appointed counsel or the waiver of fees, and if not, it directs the user to a site to help find a lawyer. Other winning apps to come out of the hackathon empower users to create health care proxies (PaperHealth) and help connect disaster victims with legal aid (Disastr).
Public Service Technology Crisis
It would be a mistake, however, to measure the event’s success solely by the technical solutions it birthed. Such a metric would reinforce the myth that hackathons are genies solving problems on-demand for the price of some coffee, pizza, and perhaps a small cash prize. The reality is more complex. Nothing built in two days will save the world, and we should not pretend otherwise.
Yet, public interest law faces a very real technology crisis, and like it or not, attorneys are information workers. Our tools matter. Biglaw is automating practice, turning routine work over to algorithms. Yet in public interest law, the state of the art is more closely aligned with the word processor, or worse, and time spent by attorneys on routine matters is time that could be better spent on clients.
Public service attorneys, their funders, and champions, including the Legal Services Corporation, have to start thinking about how to close this digital divide. So I saw the ABA Journal’s inaugural hackathon, Hackcess to Justice, as a proof of concept, a case study on the nature of collaboration and problem solving in the digital age. By those measures, it was a resounding success.
Hackathons: Scaling Proof of Concept
I am a public defender in Massachusetts, and I helped develop Due Processr along with David Zvenyach, a government lawyer in DC, and William Li, a doctoral candidate at MIT. The three of us had never worked together before, and David and William were unfamiliar with the criminal-justice system in Massachusetts. Yet, in two days, we produced a simple tool that many of my colleagues have been asking for. The story behind how we did it is worth sharing because it suggests how to attack the big problems, and spoiler alert, it has very little to do with individual personalities or individual technologies, and everything to do with tools and culture. And tools and culture scale.
To understand what makes a hackathon special, one has to understand something about what it means to be a hacker. As attorneys we often see our terms of art applied in strange ways by non-attorneys. So it should come as no surprise that the term hacker means something quite different to those working in technology than it does to the general public. In part, a hacker is someone with deep systems knowledge who delights in using that knowledge to find novel and clever solutions to problems.
When you think hacker, think MacGyver. Hackers are always trying to improve things, and you cannot improve something if you do not understand how it works. So hackers like to look under the hood, take things apart, question starting assumptions. This fosters a belief by many that information should be freely available, so anyone with a better idea can improve on what came before. This is the sentiment behind the free and open source software movements, and as Richard Stallman is often quoted, free here means free as in “free speech, not free beer.” Libre, not gratis. Such is the culture of hackathons. It is a culture of collaboration coupled with a default assumption that things can always be improved, and this is where the potential lies.
Public Defender’s Due Processr
I arrived at Suffolk University Law School, the event host, a little before nine on Thursday morning with a few ideas and my netbook. I had identified a number of points in the course of a case where one has to sit down and do some calculations. I wanted a set of mechanical tasks simple enough that they could be addressed in two days and frequent enough that their automation would actually deliver something broadly useful. I wanted to build a set of legal calculators.
After opening remarks, those who came to the event with pre-existing teams left the main hall in search of a place to work. About a dozen of us massed in the middle of the room to “pitch” projects, introduce ourselves, and take stock of our assorted skill sets. There were lawyers and developers, and lawyer-developers. Teams formed, and the work began.
David and William liked my legal calculator idea, and we found a workspace with a whiteboard. I walked them through what I thought we would need to know for each calculator and the logic behind the relevant areas of law (e.g., look to this source to find an offense’s seriousness and based on that do x or y). This is an important point. Someone had to frame the problem. Someone had to know the law. Someone needed to be there when questions came up, and that someone did not need to know a lick of code. However, (s)he needed to be an attorney, and next time, it should be you.
William was comfortable working with data sets. So he started converting the master crime list, a collection of some 1,800 offenses and their accompanying seriousness levels, into something our app could read. David began work on a counter to tally jail credit. We needed a way to coordinate the bits of code we were working on. So I set up a GitHub repository, allowing us all to work on local versions of common files, synchronizing them later.
This is where the tools were important. None of us were starting from scratch. We were all making use of open source software. These building blocks allowed us to focus on the core of our project, trusting in the work of others to assure that our site would look good on a phone and that the calculation of days would account for things like leap years. Additionally, our code is available online under an open license. So others can observe, modify, refine, and improve on our work.
In the eleventh hour, David came up with the killer name “Due Processor” (we would later sacrifice the final vowel to secure a choice URL). Friday night, we presented our project and had some pizza. In the end, the judges awarded us third place, and we called it a day.
Hackathon to Real World Application
After the event, I reached out to the MA Commissioner of Probation, whose office assists the court in its determination of indigency (who gets assigned counsel), as well as the MA Sentencing Commission, author of the sentencing guidelines. I did not receive a reply from the Commission in time for this posting. However, the Commissioner of Probation, Edward J. Dolan, invited our team to demo our app for his office. It so happens that they are in the process of developing and deploying a similar system and that they would appreciate the opportunity to compare notes. His reply was thoughtful and forward looking, recognizing the “potential of ‘expert system technology’ and its application to the work [they] do in Probation,” along with their belief that “there is a significant potential for ‘apps’ technology….” Before that reply, I had no idea where the probation service stood on these issues. Now I know. This is the ball a hackathon gets rolling.
There is a saying in software development that with many eyes all bugs are shallow. Hackathons attended by publicly minded programmers and community members make clear that we have a lot of eyes. Public interest attorneys cannot expect all of their technical needs and those of their clients to be met by an army of free (as in beer) programmers attending two-day hackathons, but the community of hackers brought together by these events can be relied on to supplement existing resources, producing a few useful tools along the way. More importantly, they provide an extra set of eyes. If we open up the code, anyone with a better idea can make improvements. That is how you provide Hackcess to Justice.