Live data from Hacker News

Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

kjzz.org

401–410 of 434 posts

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#401
post #61

With prison incentives being what they are, it’s hard not to think that it’s beneficial for the profession to hold on to inmates longer.

I'm wondering if there isn't a business model in this: couldn't the inmates (or their families) hire some law firm that calculates the correct release date and sues the state to get a hefty compensation for every day the inmates serve longer than they should? That would turn around the incentives...

Which you’re assuming that the inmates can hire an expensive law firm in the first place.

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#402
post #389

Earlier quoted context omitted.

I don't think tools cancel themselves out, and I suspect that nothing "is just" anything. Even if ideas like "the medium is the message" are partially true and then just partially applicable, that should give us pause when we try to cross out tools in our morality equations. - https://en.wikipedia.org/wiki/The_medium_is_the_message

I’m not sure what you mean by tools canceling themselves out. Are you talking about the balance between the good and bad things done with tools? If so, I do agree with you. Eg guns are tools that clearly don’t have a net benefit and controlling their manufacture and possession seems OK to me.

I was in a hurry when I typed my message, and re-reading it, I can see that it sounds a bit like babble.

I wanted to say that the tools we use impact how we behave, and that impact alone can have moral consequences. The "medium is the message" link I posted earlier talks about how the tools we use influence how we behave and experience the world. For example, if I want to tell a story, I might film a movie, or write a book, or record a radio program, or tell the story around a campfire. Each of these tools will impact the tellers, the receivers, and the story itself. This logic also applies to other more boring forms of communications. For example, using complicated software to say who gets to leave jail makes a difference in how the "tellers" and the "receivers" experience the world. To make a comparison, what if the jailer recorded information on a clipboard and paper calendar?

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#403
post #228

Earlier quoted context omitted.

The following is very illuminating: > Instead of fixing the bug, department sources said employees are attempting to identify qualifying inmates manually... But sources say the department isn’t even scratching the surface of the entire number of eligible inmates. “The only prisoners that are getting into programming are the squeaky wheels,” a source said, “the ones who already know they qualify or people who have fam…

One of the issues is that laws are made on paper and then everyone needs to figure out how to map it to software. Instead, laws should be codified in software and legal APIs should be binding. This would do wonders for efficiency, but also force laws to be cleaned up, be consistent, simple and logical.

[deleted]

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#404
post #290

> “When they legislate these things, they need to be appropriating enough money to make sure they work,” a source said. They estimated fixing the SB1310 bug would take roughly 2,000 additional programming hours. 40 hours a week times 52 weeks is 2080 hours. Subtract a few weeks for vacations and holidays, and you get a little less that 2000 hours. So, basically, this is a little more than one programmer-year of effor…

That is horse shit and we all know it. What bug takes 2k hours???? thats 250 work days. jesus christ, if I took that long to fix a bug, fire me. And yes, I'm also talking about time to test, write/fix unit tests, write/fix integration tests, releasing into production, and data conversion.

Look at the description of the issue. It's really less of a bug and more of a feature request, in the sense that the legislature changed the rules for how "earned release credits" could be calculated. All of the details are here: https://corrections.az.gov/sites/default/files/documents/PDF... .

Previously, it seems like there was a single standard, applied universally: 1 day of earned release credit for every 6 days served. The new rules have many more inputs, with lots of caveats: only certain offenses are eligible, and the inmate can not have been convicted of some other types of offenses, and the inmate must have completed some specific courses, and the inmate can't have previously been convicted of certain felonies.

The 2k hours may very well be excessive, and I don't care if it takes 20k hours, it means they should mothball their software and do it manually if that's the case, but just calling it a "bug" is misleading IMO.

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#405
post #398
post #384

Earlier quoted context omitted.

I understand that there's a lot of work that could go into this sort of thing (mocks, accessibility, testing)... but is 2000 hours really a defensible number? It sounds like there's new per-inmate data and calculations for inmate eligibility and sentencing credit. But 2000 hours worth of work? Even sand-bagging it sounds like way too much.

Of course you're assuming they have anyone left at the company that understand the software. So many times the original team that wrote it is gone, and there is a plate of spaghetti left for the next group to figure out.

It's probably worse than that. Most likely the vendor subcontracted it out to an overseas contractor that hired mostly junior-level programmers who are now working elsewhere.

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#406

Earlier quoted context omitted.

So the government writes up a spec for how the legalese should map to code that engineers then implement? How is that different from what happens now?

Only the programmed end result in code would be legally binding. Lawmakers would have a big interst in making sure the code is correct and provide incentives/change procedures accordingly. The inmates in this article would be released immediately after the code-law is implemented; you could apply new tax laws (i.e. as a config file) to your accounting software. Why maintain an obfuscated legal text when you need it i…

[deleted]

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#407
post #358

Earlier quoted context omitted.

Right, so that's just * a UI change to check the box this information is on * UI change to view whether the box is already checked or not * a data model change to store the information * business logic change that modifies some critical code that calculates when someone should be released * security/access control change to decide who is allowed to check this box * auditing logic to keep logs of this stuff * possibly…

Ok, but you must be charging by the hour if you think this is anywhere near 2000 hours of work

I’ve seen a year of dev time spent on less complexity than this a BUNCH of times in industry, and I’m not sure government is a more competent or efficient taskmaster than the Fortune 500.

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#408
post #290

> “When they legislate these things, they need to be appropriating enough money to make sure they work,” a source said. They estimated fixing the SB1310 bug would take roughly 2,000 additional programming hours. 40 hours a week times 52 weeks is 2080 hours. Subtract a few weeks for vacations and holidays, and you get a little less that 2000 hours. So, basically, this is a little more than one programmer-year of effor…

That is horse shit and we all know it. What bug takes 2k hours???? thats 250 work days. jesus christ, if I took that long to fix a bug, fire me. And yes, I'm also talking about time to test, write/fix unit tests, write/fix integration tests, releasing into production, and data conversion.

It would sure get fixed if it was releasing prisoners early.

You'd have the private prisons and the prison guards union climbing up everyone's posteriors.

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#409
post #387

Earlier quoted context omitted.

Ok, but you must be charging by the hour if you think this is anywhere near 2000 hours of work

1. Once you work for a big bureaucracy, you realize how slow this stuff is. In terms of how much actual work it takes, it depends very much on the condition of the test environment -- whether it has been maintained and how much effort is required to get back up and running. Plus, how much paperwork is involved in dealing with the government agency that contracts this out. I can easily see a situation in which you don…

I'm not saying it mightn't be 2000 hours of red tape, incompetence, and corruption. I could believe that easily enough. I'm saying it's not 2000 hours of actual work.

Re: Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

#410
When I was in jail a couple decades ago all inmates had barcoded wristbands which were scanned three times a day for accountability. On the day I was to be released I fully expected the booper to make a different sound (or something) and alert the guards that my time was up.

Nope. It beeped like normal and the guard moved on to the next inmate in line. What was I supposed to do---tell the guards that I was supposed to be released? Riiiiight. It took the actions of a guard I had befriended early on to see me later and say "What the fuck are you still doing here?" to get me out of there.

Post reply on HN