With a hat tip to Tyler Cowen [Marginal Revolution] comes a story about how Arizona is holding hundreds of prisoners past their release dates due to a software bug [KJZZ]. The problem is a well-intentioned 2019 law that gave some inmates convinced of some offenses the option to earn additional release credits upon completion of some programming in state prisons. This turned out to be entirely incompatible with how the inmate management system was designed, and as a result Arizona has been keeping release-eligible inmates imprisoned due to inflexible software design.
This is horrible, but also a great illustration of why your friendly neighborhood engineer keeps talking about technical debt.
Multiple Margins of Costs and Tradeoffs
The type of law that Arizona passed is hardly unique: an attempt to increase the fairness of governance. This can take many forms - in this case it’s to make the penal code more lenient, but in many other cases it is to make laws less lenient. These could include higher thresholds for young people to vote absentee [CNN] or to bar drug users from public services [ACLU]. But the unifying theme is to move away from value-blind implementation of a simple rule (do X, get Y) in order to advance important social values (e.g., incentivize prisoners to attend class).
Public policy is generally discussed in terms of value tradeoffs - e.g., higher fiscal costs vs. higher fairness - but less so in terms of implementation costs and error rates. It is common, for example, when introducing new government benefits to introduce “means testing”, or barring higher-income recipients from receiving benefits. The discussion is normally phrased in terms of normative values: means-testing aid so that aid goes only to the needy. What is less discussed is the complexity cost, which is completely orthogonal to those values. Introducing conditionality often involves creating more complexity, which can be harder to implement and more likely to create errors.
The more complex programs are, the higher the risk of errors or high costs on either recipients or administrators. The early release program in Arizona is an obvious example, as is the Earned Income Tax Credit (EITC) program. The program is carefully designed to incentivize work, and is well-supported by microeconomic modeling to nudge people to get jobs and work more hours. However, its complex structure is notoriously riddled with administrative errors and is prone to fraud or unintentionally unqualified claims, with the IRS estimating ~24% of payments going to unqualified recipients [CRS]. This is more or less inherent to the design, and fiddling with the parameters of the program, which on the face determine the EITC’s characteristics, won’t do much to alter the real-world consequences of how well the program services the public good.
A policy implies administration and administrative costs
The program in Arizona is almost a perfect example of what the tech community calls “technical debt” [Wikipedia]. The scheduling of prison terms is done via software, which was not designed or implemented with much forethought on how the logic of prison terms might be altered in the future. When the Arizona government decided to introduce additional conditions into the schedule, the software was not able to keep up with the change.
This happens continuously throughout every large institution - we often have desires to implement complex changes to match our values, without taking into account the fact that added complexity may stymie progress towards those values. The complexity of rules introduces in itself a type of technical debt, for example in the federal tax code where the sheer complexity of the rules often makes it hard to evaluate the substantive changes that might be introduced by new changes or provisions.
Simplicity really does have a value for simplicity’s sake, and as more and more of the world is mediated by software instead of human discretion the value of simplicity is only going to grow.