Live data from Hacker News

Whistleblowers: Software keeping inmates in Arizona prisons beyond release dates

kjzz.org

31–40 of 434 posts

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

#32

Earlier quoted context omitted.

But even if it was a bug... I don't understand why software would prevent somebody opening the gate and letting the inmate out...

1.5 million prisoners in the USA. You want to go through that list, without software?

If the list is public, we can at least do the math independently to hold corrections departments accountable (filing suit to release eligible inmates when corrections won’t voluntarily release because of “software enhancements waiting to be built”).

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

#33
post #10

The fact that they appear to have identified individuals who should be released, but have not, due to the software not being updated, is frankly disgusting. I believe holding a person against their will is a criminal act - seems like most of the employees of the Arizona correctional facilities are now guilty of crimes worse than the majority of their inmates.

Except the people in the system have immunity.

Even laws like kidnapping have a motive portion, and basically an incompetent cop or other official can do what they and just claim they sucked at their job so the motive portion can't be met.

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

#34
post #6

This isn't a "bug". The problem is the software was not designed to do this and needs to be updated to support a change in requirements Bugs are when software does something it isn't supposed to, or doesn't do something it is supposed to. In this case, it's doing exactly what it was intended to do when it was implemented and put into service. Since then things have changed, so the vendor needs to implement the featur…

This is why I think custom software contracting and vendorization is a “noob-trap”. Software needs to be updated and maintained and you never know when you start writing it what the real requirements are. If I were a taxpayer in this state I’d be angry that my money would be going to a series of middlemen (e.g. a procurement consultant, program manager on the gov side, a contractor manager, the contracting company’s…

C'mon, that's Big Government. We all know that's the least efficient form of production possible.

/s

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

#35
post #21
post #6

This isn't a "bug". The problem is the software was not designed to do this and needs to be updated to support a change in requirements Bugs are when software does something it isn't supposed to, or doesn't do something it is supposed to. In this case, it's doing exactly what it was intended to do when it was implemented and put into service. Since then things have changed, so the vendor needs to implement the featur…

Seems high, but this is par for the course for this type of work. You would usually estimate this in terms of months for a team. Let's say a team of 4 for simplicity -- that brings it to ~3 months. I'd also be careful with the term "programming hours". I'm not sure how the news article got that or who said that initially, but it seems like a misrepresentation of the type of work needed. That estimate almost certainly…

Sounds like the QA wasn’t very good from the beginning considering the number of actual bugs reported.

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

#36
post #10

The fact that they appear to have identified individuals who should be released, but have not, due to the software not being updated, is frankly disgusting. I believe holding a person against their will is a criminal act - seems like most of the employees of the Arizona correctional facilities are now guilty of crimes worse than the majority of their inmates.

Computer says no.

I'm sorry Dave, I'm afraid I can't do that.

(and I'm not making fun of this - it's not a situation I would wish to be)

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

#37
post #10

The fact that they appear to have identified individuals who should be released, but have not, due to the software not being updated, is frankly disgusting. I believe holding a person against their will is a criminal act - seems like most of the employees of the Arizona correctional facilities are now guilty of crimes worse than the majority of their inmates.

Computer says no.

Computer cited as authoritative basis, we see a lot of that these days.

Metal hand, flesh puppet.

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

#38

Earlier quoted context omitted.

But even if it was a bug... I don't understand why software would prevent somebody opening the gate and letting the inmate out...

1.5 million prisoners in the USA. You want to go through that list, without software?

There's 1.5 million people right there who might be interested.

Even 0.07% of them, say about 1000 people, might volunteer to learn the code base and programming language.

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

#40
post #5

I'd hesitate to call this a software bug, this is a complete breakdown of planning. FTA - "“Currently this calculation is not in ACIS at all,” the report states. “ACIS can calculate 1 earned credit for every 6 days served, but this is a new calculation.”" tldr; a new law was passed that allowed for a different credit schedule for days served, and the system hasn't been updated to make that calculation.

It's the problem with silver bullets like YAGNI: Laws change, if your system is dependent on laws, then you can be sure that new rules will need to be added. You need a system that is configurable, you can be sure you are going to need it. Of course, if there's money to be made in having a change-resistant system, well that's a different story. YAGNIAYWPTTNFI (You ARE gonna need it, and you will pay through the nose…

> if your system is dependent on laws, then you can be sure that new rules will need to be added. You need a system that is configurable, you can be sure you are going to need it.

This doesn’t violate YAGNI.

1. You’d have to know in advance what the scope of rule changes would be in order to implement the configuration system.

Human laws do not fit this constraint.

2. You’d also need a way to prove that the configuration system itself was sound.

3. You’d need a way to test configurations to make sure they executed as expected.

That is likely to be no better than just updating the codebase as requirements change, and there are many ways it could increase the cost.

Post reply on HN