Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

kjzz.org

Post reply on HN
Print view View original

391–400 of 434 posts

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

#391

Post by Bakary »

bitL wrote: post #282
frompdx wrote: post #20

This is an outrage. It is also a perfect example of how software is used to create increasingly more elaborate and faceless bureaucracies that force individuals to spend more and more time contending with them. Somehow software has become the ultimate vehicle for bureaucratic violence. Software is simultaneously infallible and the perfect scapegoat. The inmate who lost their phone privileges for 30 days is an example…

> if the software we are building is making the world a better place No, it's now all about "extracting value", "rent seeking", "subscriptions", "censorship", "monopoly" and "control". We got bribed by FAANG and this is the consequence.

Bribed implies the natural course of the tech worker would be altruistic, which is quite the assumption

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

#392

Post by maybenotafart »

elihu wrote: 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.

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

#393

Post by maybenotafart »

ipsin wrote: post #384
elihu wrote: 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…

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.

sounds much more like budget politics against the incompetent

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

#394

Post by ohboichamois »

jdeibele wrote: post #76

When I wanted to have compiled [1] financials, PriceWaterhouseCoopers told me to pick a recognized accounting system, then change the company's business processes to match that. They said absolutely not to go the other way, to try to customize any software to match our business. I think about that every time I read about another government (or private!) company that wastes tens or hundreds of million of dollars (or e…

FWIW this is actually (mostly) the case for building codes. The standard in the USA is the International Building Code (and other related code by the International Code Council), which each jurisdiction adopts into law and amends as needed for local conditions or practices. And these codes in turn reference other international standards specific to the knowledge domain.

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

#395

Post by codyb »

ipsin wrote: post #384
elihu wrote: 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…

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.

I was pretty incredulous until a cousin poster started talking about auditing, testing, red tape, out of date systems, and security.

Seems plausible it could balloon.

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

#396

Post by ByteJockey »

ethbr0 wrote: post #291
munk-a wrote: post #243

Earlier quoted context omitted.

> Comments like yours seem to glorify a pre-software world filled with manual entry. The reality is that manual entry is even more error-prone, bias-prone, with more people falling through the cracks. I think that the pre-software world was quite bias-prone and extremely expensive for large processing jobs like this. The question is how this system was allowed to transition from the expensive manually managed system…

The problem is that we never evolved COBOL / VB. Or we did, but then used the resulting easier-to-learn / easier-to-write languages exclusively for web dev, and further specialized them. There's a mind-bogglingly huge chasm of simple business data processing software that has no performance requirements & no need to be written in an impenetrable language. Any one of the employees there could probably tell you what sh…

>You can optimize along increase-developer-productivity or along increase-potential-developer-population. We chose the former.

I have to ask. How could it be any different?

The vast majority (all?) of the languages are made by devs. Devs work harder and produce better code when they're working on something they want to use.

And the mainstream corporate-sponsored languages (Java, C#, Go) all seem to have started with groups of devs that really didn't want to use C++, which provides roughly the same incentives.

The kind of drive needed to develop and maintain a solid language (to say nothing about an easy to work with language) kind of has to be a passion project, and people aren't generally able to choose what they're passionate about.

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

#397

Post by causality0 »

Isn't not fixing this deliberately falsifying records and hence a criminal act? This is like having a physical date stamp whose counter is stuck on the wrong day and choosing to keep stamping the wrong date on paperwork because you don't think it's worth fixing.

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

#398

Post by pixl97 »

ipsin wrote: post #384
elihu wrote: 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…

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.

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

#399

Post by oh_sigh »

WalterBright wrote: post #313
TexasfoldsEm wrote: post #249

Wow. I know firsthand from family how this can severely destroy someone's mental health in what may not be so obvious; it is extremely heavy on someone every moment past the first hour they go past their release time, then the first day followed by a variety of things that will then be taken advantage of by other inmate and guards while one's defenses are down. The fun poked at by other jealous inmates and cruel guar…

If a prisoner knows he's past his release date, can't he contact his lawyer?

Sure, that still takes time to get through the system though. Probably months between scheduling and final release.

More commonly though the people wouldn't even know to contact their lawyer, because they are credited for time served pre-conviction.

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

#400

Post by adrianN »

maybenotafart wrote: post #392
elihu wrote: 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.

You don't know the codebase. Even people who know a codebase have a hard time giving accurate estimates.
Post reply on HN