9 ms·

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

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 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.

WrtCdEvrydy 6y ago
Pay the money or the inmates stay in prison for longer... weird hostage negotiation but okay...
rileymat2 6y ago
There is a lot of reasonable opinions on the topic, but I would consider design and requirements bugs that render the software unfit for purpose to be bugs as well.
- lbriner 6y ago
  If they were design and requirements then fine, but you cannot consider something that was not asked or paid for as a bug. As with many cock-ups, somebody did not know enough to ask for the right thing. 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.
  - tshaddox 6y ago
    It’s still a bug, even if the project managers or software engineers are not responsible for causing the bug. I think people are just using “it’s not a bug” to mean “it’s not my fault as a member of the software engineering team.” But of course there are bugs which are not the software engineering team’s fault.
londons_explore 6y ago
1 person-year is pretty much the smallest labor unit when quoting for modifications to government contracts. 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.
- mywittyname 6y ago
  Once you've executed on enough of these contracts, you develop an idea of what the unknown-unknowns are and plan for them. 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.
- caturopath 6y ago
  We did tons of tiny contracts when I was working in government contracting (DOD/DOE).
  - deefour 6y ago
    Okay?
    - caturopath 6y ago
      So my experience (government contracts have a floor of one person-year) doesn't match my experience with government contracts.
- deleted 6y ago
  [deleted]
opportune 6y ago
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 cut) rather than some state employed software developer.
- monadic5 6y ago
  C'mon, that's Big Government. We all know that's the least efficient form of production possible. /s
- lbriner 6y ago
  Sorry but this is just a question of balance. 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.
- mattmcknight 6y ago
  Unfortunately the pay scale for state software developers never (I almost never say never) has a proper differential over other employees with the same level of experience, meaning they are often below 10th percentile of market rate, and thus the employees that end up in those jobs tend to be among the least skilled and motivated people I've ever dealt with. Even though contractors mess up, you can fire them. What's probably better is to keep a contractor available on an hourly rate for maintenance like this, rather than pay per change order. 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".
plif 6y ago
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 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.
- azinman2 6y ago
  Sounds like the QA wasn’t very good from the beginning considering the number of actual bugs reported.
  - plif 6y ago
    Not trying to defend anyone, but I'm sure we can find many other reasons why there are so many bugs here unrelated to QA :)
    - worik 6y ago
      What is QA if it cannot be blamed for low quality?
      - vntok 6y ago
        If the specs are bad, QA will find low quality spots of undefined behaviour (anything goes, ergo it's fine), or even actual logic issues in the specs. However the software is coded to specs, not to QA's own desires, so the bugs stay.
      - plif 6y ago
        It's a rubber stamp like many other things in this development model. 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.
crummybowley 6y ago
But even if it was a bug... I don't understand why software would prevent somebody opening the gate and letting the inmate out...
- MattGaiser 6y ago
  They might only know that it is not calculating some sentences correctly. That does mean they have figured out little more beyond "we know it is wrong."
- JoeAltmaier 6y ago
  1.5 million prisoners in the USA. You want to go through that list, without software?
  - toomuchtodo 6y ago
    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”).
    - Firehawke 6y ago
      Not that simple. There are behavioral factors that can affect a prisoner's status and that particular information would never be public. 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.
      - toomuchtodo 6y ago
        I agree it's not simple. I am advocating for activist (engineering, political, etc) efforts against The Bureaucracy. Public data is a component of that, from a transparency and accountability perspective, very similar to FOIAing everything you can get your hands on (ie muckrock.com). You want to be able to "show your work" in broad daylight.
hinkley 6y ago
The problem with government contracts is that they are very much the class of customer who does not understand software requirements. They have all the worst aspects of a small company that doesn't understand software and so keeps whip-cracking the architecture, and all of the bureaucracy of a government with institutionalized PTSD about contract fraud and bribery. 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.
phamilton4 6y ago
To be frank, you probably want this solution to be vetted out pretty well. I really don't want to think of cases where the wrong person was let go. The sizing is what 12 people x 40 for 4 weeks? Really not that extreme for large projects. I also don't understand why they can't identify these people and release them by other means...
jrochkind1 6y ago
We all know that it takes more skill (and experience and domain knowledge), and more time up-front, to create software that is easier/cheaper to change later in response to changed requirements. 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.”
aksss 6y ago
I’d not be too quick to dismiss the estimate. If you were asked to change a couple nested if statements in a prison’s guest management system, probably written in Natural, RPG, and Cold Fusion or some other obscure combo of tools, you’d be silly not to take a step back and be careful with your bidding. 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.
brundolf 6y ago
I posted under another comment, but this to me is a software-literacy problem. You shouldn't have to hire an engineer to fix or adjust business rules in 2021. Period. The people who know the domain should be able to maintain (and really, create) any automation of that domain themselves. 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.
- cynoclast 6y ago
  >The people who know the domain should be able to maintain (and really, create) any automation of that domain themselves. 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.
dang 6y ago
OK, we've taken the bug out of the title above. It allows the whistleblowers to squeeze in, which is nice. It might be good to have a non-terminological discussion now. Though this subthread isn't too bad.

WrtCdEvrydy 6y ago

Pay the money or the inmates stay in prison for longer... weird hostage negotiation but okay...

rileymat2 6y ago

There is a lot of reasonable opinions on the topic, but I would consider design and requirements bugs that render the software unfit for purpose to be bugs as well.

lbriner 6y ago
If they were design and requirements then fine, but you cannot consider something that was not asked or paid for as a bug. As with many cock-ups, somebody did not know enough to ask for the right thing. 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.
- tshaddox 6y ago
  It’s still a bug, even if the project managers or software engineers are not responsible for causing the bug. I think people are just using “it’s not a bug” to mean “it’s not my fault as a member of the software engineering team.” But of course there are bugs which are not the software engineering team’s fault.

londons_explore 6y ago

1 person-year is pretty much the smallest labor unit when quoting for modifications to government contracts. 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.

mywittyname 6y ago
Once you've executed on enough of these contracts, you develop an idea of what the unknown-unknowns are and plan for them. 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.
caturopath 6y ago
We did tons of tiny contracts when I was working in government contracting (DOD/DOE).
- deefour 6y ago
  Okay?
  - caturopath 6y ago
    So my experience (government contracts have a floor of one person-year) doesn't match my experience with government contracts.
deleted 6y ago
[deleted]

opportune 6y ago

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 cut) rather than some state employed software developer.

monadic5 6y ago
C'mon, that's Big Government. We all know that's the least efficient form of production possible. /s
lbriner 6y ago
Sorry but this is just a question of balance. 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.
mattmcknight 6y ago
Unfortunately the pay scale for state software developers never (I almost never say never) has a proper differential over other employees with the same level of experience, meaning they are often below 10th percentile of market rate, and thus the employees that end up in those jobs tend to be among the least skilled and motivated people I've ever dealt with. Even though contractors mess up, you can fire them. What's probably better is to keep a contractor available on an hourly rate for maintenance like this, rather than pay per change order. 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".

plif 6y ago

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 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.

azinman2 6y ago
Sounds like the QA wasn’t very good from the beginning considering the number of actual bugs reported.
- plif 6y ago
  Not trying to defend anyone, but I'm sure we can find many other reasons why there are so many bugs here unrelated to QA :)
  - worik 6y ago
    What is QA if it cannot be blamed for low quality?
    - vntok 6y ago
      If the specs are bad, QA will find low quality spots of undefined behaviour (anything goes, ergo it's fine), or even actual logic issues in the specs. However the software is coded to specs, not to QA's own desires, so the bugs stay.
    - plif 6y ago
      It's a rubber stamp like many other things in this development model. 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.

crummybowley 6y ago

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

MattGaiser 6y ago
They might only know that it is not calculating some sentences correctly. That does mean they have figured out little more beyond "we know it is wrong."
JoeAltmaier 6y ago
1.5 million prisoners in the USA. You want to go through that list, without software?
- toomuchtodo 6y ago
  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”).
  - Firehawke 6y ago
    Not that simple. There are behavioral factors that can affect a prisoner's status and that particular information would never be public. 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.
    - toomuchtodo 6y ago
      I agree it's not simple. I am advocating for activist (engineering, political, etc) efforts against The Bureaucracy. Public data is a component of that, from a transparency and accountability perspective, very similar to FOIAing everything you can get your hands on (ie muckrock.com). You want to be able to "show your work" in broad daylight.

hinkley 6y ago

The problem with government contracts is that they are very much the class of customer who does not understand software requirements. They have all the worst aspects of a small company that doesn't understand software and so keeps whip-cracking the architecture, and all of the bureaucracy of a government with institutionalized PTSD about contract fraud and bribery. 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.

phamilton4 6y ago

To be frank, you probably want this solution to be vetted out pretty well. I really don't want to think of cases where the wrong person was let go. The sizing is what 12 people x 40 for 4 weeks? Really not that extreme for large projects. I also don't understand why they can't identify these people and release them by other means...

jrochkind1 6y ago

We all know that it takes more skill (and experience and domain knowledge), and more time up-front, to create software that is easier/cheaper to change later in response to changed requirements. 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.”

aksss 6y ago

I’d not be too quick to dismiss the estimate. If you were asked to change a couple nested if statements in a prison’s guest management system, probably written in Natural, RPG, and Cold Fusion or some other obscure combo of tools, you’d be silly not to take a step back and be careful with your bidding. 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.

brundolf 6y ago

I posted under another comment, but this to me is a software-literacy problem. You shouldn't have to hire an engineer to fix or adjust business rules in 2021. Period. The people who know the domain should be able to maintain (and really, create) any automation of that domain themselves. 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.

cynoclast 6y ago
>The people who know the domain should be able to maintain (and really, create) any automation of that domain themselves. 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.

dang 6y ago

OK, we've taken the bug out of the title above. It allows the whistleblowers to squeeze in, which is nice. It might be good to have a non-terminological discussion now. Though this subthread isn't too bad.