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.
I'm guessing up til now, the days of time off earned was done in real time. Basically all you need is the day they entered, divide by 6 and truncate and there's your days. If there are infractions that cost days, you could still probably do it in a single SQL query.
This new system will have to know what kind of crime they committed, which might mean integrating with some byzantine government software from the 90s that looks like it's from the 70s. Previously they only really needed the prison system's records, which may or may not include their past crimes.
I'm guessing they're worried the integration won't be as easy as proposed. I wouldn't be surprised if it takes a month just to get the dev access to everything. I might even be surprised if it was that short.
You'd have the private prisons and the prison guards union climbing up everyone's posteriors.
Spending money will remain economic decision until we can have government agencies fueled by the righteous indignation of their critics rather than having a line item added to their budget. Until you can convert that indignation into legal tender, agencies will remain subject to old fashioned accounting constraints.
* 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 new UI/management code to add/remove members to this group of people who can check the box
* together with adding some procedures for tracking who completes what, documentation, training and auditing.
* Testing the whole thing.
Probably for piles of who knows what where the original author is long gone and the test code is no longer functional.
Just to keep things in perspective.
2. What I described is not the actual fix, it is the temporary stopgap. The prison department isn't going to pay someone to click checkboxes all the time for tens of thousands of inmates each year. They will want this info to be set automatically -- e.g. an integration from whatever software system(s) are used to track completion of the coursework to this system, so you are not hiring another employee to sit and click all the time nor do you need to create reporting procedures to get that info into the hands of the person who is clicking. The appropriate design then requires automation, which will require security controls, and it's a pain. It could easily be more than a year of work, again depending on how many systems they need to integrate against, what types of sign off/controls are required, how much paperwork is required, etc.
For example, maybe the coursework has no software tracking, in which case they need to throw up a portal and have the people running the course fill out who did what, and then throw up another portal to have someone else review that.
Lots of stuff ends up being passed around by ftp or csv uploads. I've seen horror stories. So it really depends on how they plan to do this integration -- the manual button clicking was just an example of a least effort system that relied on a lot of manual labor, but perhaps this is not in their budget either.
Yes, it's a few weeks of coding at best. Maybe more if they need to integrate with some external systems for data ingestion.
But it's not a lean agile MVP for a startup. Redtape is just as much a deliverable as the function itself.
And 2000 hours for a 4 person team is a quarter of a year. Sure it might take less for a full stack ninja with 5 years of rockstar experience, but those folks are not available for some reason (Pink Floyd - Money!).
Seems plausible it could balloon.
I’m surprised this doesn’t create a massive liability for the state.
That would basically result on patients not getting their ostomy bags on time, and I can't even imagine what would follow afterwards. What would be the reactions of patients and their relatives, what levels of stress would hospitals' employees would be subjected to, and so on.
I left the company some months after that, and I don't know what was the final decision, but they'd been warned.
Maybe one day some set of ethical standards will be considered non-functional requirements as important as robustness, security and others.
With technicians being responsible for warning their managers, managers being responsible for assessing risks and documenting their decisions, everything being made transparently and everybody being accountable.
That this problem is allowed to persist seems like an indication that the people in charge believe that prisoners have a low probability of successfully suing the state for damages.
If Arizona isn't acting quickly enough, I wonder if the federal government can get involved?
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 effort if the estimate is in the right ballpark.
It's gross that the decision not to fix this carries an apparent implicit economic calculation that one programmer-year is more valuable than the freedom that is being denied to an unknown number of people whom society deems less important. (Granted the actual situation is more complicated and the state is constrained by their contract with the vendor, which we can reasonably guess is going to charge as much as they can contractually get away with rather than the programmer's actual salary cost.)
At least the Department of Corrections has assigned people to do the calculations manually. That's better, but it sounds like they just don't have enough people on it to keep up.