> 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 that used to be in place to the automatic software driven system that is replacing it at such a cut-rate that gigantic bugs were allowed to sneak in.
It appears this software is primarily used by the state government so why was such a poor replacement allowed as a substitute for the working manual process.
Also, the number of bugs this software has accumulated since Nov 2019 (14000) is astounding enough that I assume it's counting incidents - that's a fair way to go since these are folks' lives, but I'd be curious to know just how bug laden this software actually is.
Although there is another factor here - this specific release program was a rather late feature addition that may not have been covered in the original contract with ACIS since the bill was only signed into law two months before the software was rolled out.
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 should be done in each case, and it's an indictment of our profession that we haven't created a good language / system that lets them do so.
You can optimize along increase-developer-productivity or along increase-potential-developer-population. We chose the former.
>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.
Probably like most government purchases, lowest bidder wins as long as they show on paper that they can do the job. Whether they execute on that is another matter, and some times the subpar work is accepted because of contract issues, sunk cost fallacy, politics/reputations, or schedule.
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 that used to be in place to the automatic software driven system that is replacing it at such a cut-rate that gigantic bugs were allowed to sneak in.
It appears this software is primarily used by the state government so why was such a poor replacement allowed as a substitute for the working manual process.
Also, the number of bugs this software has accumulated since Nov 2019 (14000) is astounding enough that I assume it's counting incidents - that's a fair way to go since these are folks' lives, but I'd be curious to know just how bug laden this software actually is.
Although there is another factor here - this specific release program was a rather late feature addition that may not have been covered in the original contract with ACIS since the bill was only signed into law two months before the software was rolled out.