4 ms·

This idea is too simplistic. Although I used to support it. I've changed my position from yours to 'retrained and demotion' position. Since people make mistakes

This idea is too simplistic. Although I used to support it. I've changed my position from yours to 'retrained and demotion' position. Since people make mistakes, I think being 'barred from further work' is counter-productive and the government would lose out on many able and competent workers. Heck, this idea could also be exploited by lower-level workers due to not liking their higher-up bosses; i.e. a lower-level worker intentionally screwing up and costing the job of the higher-up boss because of the 'new law' stating the higher-up is now 'barred' from further govt work. Easy way to take out the competition going up a ladder. P.S. I think legislating accountability is an issue the public needs to debate. In all countries. The US has seen numerous gross negligence/errors (heck one is too many) in various levels of govt (fed, state, local). I hope we can come up with a better solution than 'fire them and bar them' and even mine of 'demote/retrain'. There has to be a better way to legislate govt accountability.

PakG1 10y ago
Indeed, such ideas would create an atmosphere of fear and increase cover-ups, rather than solve problems. There needs to be a solution that acknowledges the inevitably of mistakes and still deals with the issue.
- iamflimflam1 10y ago
  Exactly this. How many of us would be up in arms if developers were fired for making mistakes? You just need to look at all the stories around rm -rf...
  - tmptmp 10y ago
    so what if tomorrow your bank says it has lost all records due to programming/tech error? who is responsible there? why is such sensitive data (air force etc) should be treated differently than cash/finance data?
  - emp_zealoth 10y ago
    Maybe thats exactly what should happen? I mean, whole "security" antics where companies loose tens of millions of logins/credit cards numbers and it all ends with "southpark BP apology" People fuck up epically and get a slap on a wrist with a promotion, I mean, come on
sametmax 10y ago
If you have backup, a crash won't lose months of data. I'm ok to lose a so called "competent worker" if he/she hasn't been doing something as simple as off-site backup. It's local data corruption here. At worst you loose the data since the last backup. Now, in the army, they have redundancy procedures for everything, and you want to make us believe the one server used to keep them in check, not only had crash beyong repair, but has no backup ?
- fabled_giraffe 10y ago
  You'd be surprised how tenuous backup situations are at most companies and organizations. Even if your company is doing full disaster recovery checks 24/7, one after the other, a "well-placed" failure/mistakes or small series of failures/mistakes can lead to data loss. Many of the things that cause data loss are just simple mistakes caused by a failure to review changes carefully, even when you have multiple levels of review- I would dare to say especially when you have high confidence that someone else is reviewing your changes. "Manual" data changes, e.g. executing SQL statements or scripts that execute SQL that aren't a part of your application, in my experience are the most common cause of data loss. After manual data changes the second most common in my experience is not understanding what you are doing. For example, you might take a chance on an upgrade that fails because you have to meet a deadline. Changes to application code are next. Typically when making changes to an application, a little more thought may be put into it than a one-off data migration or change, but if you are under time pressure, don't know what you are doing, or are assuming someone else will catch your mistakes, you could easily screw everything. Following this- mistakes that cause hardware or software failure. I worked at one large organization where storage arrays with various power backups were just "turned off" by a contractor that didn't understand the impact of what he or she was doing. Finally, you might have configuration issues or the hardware might just fail. Really, there is no substitute for having your data backed up frequently, and in a way you know how to easily restore and have tested, by building another machine from the ground up to replace it and documenting and practicing that well. Very few do this frequently. And even if you do- what if all of your hardware were destroyed? Can you easily go out and buy something off the shelf with instructions you have in your head or stored safely around the world and rebuild everything?

PakG1 10y ago

Indeed, such ideas would create an atmosphere of fear and increase cover-ups, rather than solve problems. There needs to be a solution that acknowledges the inevitably of mistakes and still deals with the issue.

iamflimflam1 10y ago
Exactly this. How many of us would be up in arms if developers were fired for making mistakes? You just need to look at all the stories around rm -rf...
- tmptmp 10y ago
  so what if tomorrow your bank says it has lost all records due to programming/tech error? who is responsible there? why is such sensitive data (air force etc) should be treated differently than cash/finance data?
- emp_zealoth 10y ago
  Maybe thats exactly what should happen? I mean, whole "security" antics where companies loose tens of millions of logins/credit cards numbers and it all ends with "southpark BP apology" People fuck up epically and get a slap on a wrist with a promotion, I mean, come on

sametmax 10y ago

If you have backup, a crash won't lose months of data. I'm ok to lose a so called "competent worker" if he/she hasn't been doing something as simple as off-site backup. It's local data corruption here. At worst you loose the data since the last backup. Now, in the army, they have redundancy procedures for everything, and you want to make us believe the one server used to keep them in check, not only had crash beyong repair, but has no backup ?

fabled_giraffe 10y ago
You'd be surprised how tenuous backup situations are at most companies and organizations. Even if your company is doing full disaster recovery checks 24/7, one after the other, a "well-placed" failure/mistakes or small series of failures/mistakes can lead to data loss. Many of the things that cause data loss are just simple mistakes caused by a failure to review changes carefully, even when you have multiple levels of review- I would dare to say especially when you have high confidence that someone else is reviewing your changes. "Manual" data changes, e.g. executing SQL statements or scripts that execute SQL that aren't a part of your application, in my experience are the most common cause of data loss. After manual data changes the second most common in my experience is not understanding what you are doing. For example, you might take a chance on an upgrade that fails because you have to meet a deadline. Changes to application code are next. Typically when making changes to an application, a little more thought may be put into it than a one-off data migration or change, but if you are under time pressure, don't know what you are doing, or are assuming someone else will catch your mistakes, you could easily screw everything. Following this- mistakes that cause hardware or software failure. I worked at one large organization where storage arrays with various power backups were just "turned off" by a contractor that didn't understand the impact of what he or she was doing. Finally, you might have configuration issues or the hardware might just fail. Really, there is no substitute for having your data backed up frequently, and in a way you know how to easily restore and have tested, by building another machine from the ground up to replace it and documenting and practicing that well. Very few do this frequently. And even if you do- what if all of your hardware were destroyed? Can you easily go out and buy something off the shelf with instructions you have in your head or stored safely around the world and rebuild everything?