If the government wants to change the logo on the login screen, they're gonna pay 1 person-year. Why would I quote less? It'll take over 1 person-year for another contractor to pick up and start supporting the codebase, and we won't support a codebase that another contractor has touched.
It's just the nature of government IT. Lowball the initial quote, then charge massively for any modifications and support now they're locked in.
It's government work, which automatically means access issues, dozens (or hundreds) of stakeholders requesting meetings, internal politicking, back-and-forth over change requests, etc. All of that costs real money and if you don't plan for it or make contingencies, you're going to be screwed.
These issues are not just limited to government either; any sufficiently large entity will have these same problems. So yeah, one person-year is a reasonable minimum viable contract period unless you have a process in place to fast-track RFP approval.
but I'm not sure how's the reality.
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 cut) rather than some state employed software developer.
I also find the government "requirements" process tends to create situations like this. Rather than build flexible software that puts some degree of trust in the person using it, they tend to overspecify the current bureaucratic process. In many cases, the person pushing for the software is looking to use software to enforce bureaucratic control that they have been unable to otherwise exercise, with the effect of the people the project initiator wants to use the software simply working around it. They then institute all sorts of punishments and controls to insure it must be used. This then results in the kind of insane situation we have here, where you can't do something perfectly legal because "computer says no".
This. The job itself is terrible and as you mention the pay is terrible too. With conditions like that, I'm not surprised the product is buggy, over-budget, and difficult to improve.
It gets complicated but there are some simple rules to follow. If you are running a non-competitive RFP then that might be okay because you are running a competitive RFP and so you get these opportunities to leverage your competitors, use one of the other competitive RFP rules for other projects, to use your competitor's RFP, etc. but you need to make sure the RFP you are running only does what the competition isn't allowed to do.
"Salaries at USDS vary, but don’t exceed $170,800, determined by your experience and skills." So, they do have a relatively low top salary, but it is very difficult to do any salary for the government based on skills versus age (disguised as years of experience). At best you might find adjustments for degrees earned, which don't translate well to actual value.
Sure, it sounds like a public-sector employee gives better value but if you want to produce commercial quality then you still need management, consultancy and high quality HR with competitive salaries, otherwise you usually get mediocre developers with mediocre results.
Sometimes it really is better to pay a premium on the "day rate" to get something more quickly and to a higher standard. You also often have access to better support and maintenance.
You pays your money and takes your choice.
Are you willing to pay market rates to retain that developer? Or deal with the constant churn as people stay long enough to pad their resume before moving along to the next job?
I mean things probably seem to the outside like “it’s just two lines of code”, but if you’re messing with the business logic of releasing prisoners I’m sure you’d want to document how things currently work pretty thoroughly (inferred requirements), test/validate, have customer sign off on the existing functionality, make your change, re-run all the testing, requirements verification, etc. There’s probably a business analyst involved, a programmer, maybe even dedicated test manager, devops (do they have an existing dev/test system?). People in the prison bureau probably take their jobs seriously on paper, don’t want this change to cause more breakage than it fixes, and expressed that in the RFP.
- System needs to track sexual offenders and provide updates on their locations to relevant municipalities
- Parole officer check, requirements, and termination system needs to know who, what, and where
- Statistical record-keeping systems for sentence lengths need to be updated
- If felons, voting systems need to be kept updated
All of these sorts of actions would be triggered by someone’s release and probably involve interconnected systems that rely on truth data about the initial release.
One major thing my career in software and systems has taught me is that things are rarely as simple as they seem on the surface. I tend to approach such systems with humility.
How much would that cost you? And how much is a day of a free man's life worth to you?
This is a travesty and that sum of money is neither sufficient, nor unique to the GP's solution.
That's a rather broad blanket statement bordering on collective punishment (which BTW is classified as a war crime by the UN). The status of taxpayer makes you a victim of the state, not necessarily someone with influence over its behavior and certainly not an ardent supporter of all its policies. The vast majority of the taxpayers had nothing to do with the situation and might well be opposed to keeping these people in prison if the facts were explained to them.
Perhaps the matter should be put to a general vote—those actually in favor of keeping the inmates in prison can split the cost of any wrongful-imprisonment suit in the event the state loses.
Also, if you release someone and the system still shows them as being in there, that could lead to a very bad interaction for that person if they have any official interaction with authorities while they are out.
Not a terrible stretch. You are probably correct.
Or, more likely, it lacked the manual override mechanism at all.
Getting into prison is easy but getting out is really hard and will take you years even if everybody agrees a mistake was made.
https://slate.com/news-and-politics/2015/03/innocence-is-not...
Apparently, they can let them out on time if they calculate the release date and enter it into the system manually.
Maybe we'd have better results if inmates could file paperwork to receive the payments that would normally go to the prison for their imprisonment, starting on the date they should have been released.
https://www.stltoday.com/news/national/govt-and-politics/ari...
It's a full-on bureaucracy where only the computers actually know the correct full calculation for every prisoner due to the complexity of the formulas, and when the computers can't do that correctly people get screwed with no recourse because it's humanly impossible to keep up with every detail.
Even 0.07% of them, say about 1000 people, might volunteer to learn the code base and programming language.
If you have a choice between the regional furniture store and your state government, I'd have a hard time advising you on which one will suck less. It's a tossup. If the owners of the furniture store are old enough to have heirs who are late teens to 30-something, take the furniture store, because you can ask them to intervene.
At some point you have to pay the bills. And destress your employees who are constantly having to hurry up and wait.
On top of that, someone should have been in the room to tell the State Governor that their proposed change was not supported in software and needed something out-of-band to manage it.
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 includes everything involved in getting the code to production. You can imagine that means a lot of QA, red tape and holding the code's hand through environments.
Not saying their QA is useful, but it's not tough to imagine their QA being many layers removed from decision making. ie: Program Manager -> Product Owner -> Project Manager -> Business Analyst -> QA -- not even mentioning reporting lines.
That person in QA at the end of the chain is likely following a script written & approved by the layers above them to a T. It's highly unlikely that they are empowered to go off script or raise tangential issues. Doing so may even cost them their job.
However the software is coded to specs, not to QA's own desires, so the bugs stay.
If you got the cheapest possible software up-front that (barely, technically) met the original requirements, you did it by hiring the least skilled people that could barely pull off exactly what would get the contract paid, and asking them to rush and hurry and pile up technical debt.
So.
In this case, the software perhaps shouldn't have even been considered fulfilling the contract in the first place, that's how crappy it was. The crappier the software, the more expensive changes to it are, we all know that.
> One department whistleblower said the number of problems with the ACIS system was unprecedented in their professional experience. “I have never in my life run across an application like this,” they said. “It’s just been one big cluster.”
I also don't understand why they can't identify these people and release them by other means...
This is partly a failure of education, partly a failure of organizational structuring, and partly a failure of software accessibility. But it's a gargantuan failure all the same.
This is a recipe for disaster 100% of the time. One needs to know both the domain and software to change software in the domain. People who 'know the domain' but not software, when given the tools to modify software within the domain inevitably create an unmaintainable rats nest of more difficult to change rules, almost invariably in some proprietary WYSYWIG tool that creates more problems than it solves.
It might be good to have a non-terminological discussion now. Though this subthread isn't too bad.
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 feature request, not "fix the bug", but this takes time.
> They estimated fixing the SB1310 bug would take roughly 2,000 additional programming hours.
wtf?
Guessing they estimated 1 person-year, but that's absurdly high.