5 ms·

A computer failure. Again. We have been doing payroll for over seventy years. To fail to implement a payroll is a dreadful mistake, and a person is responsibl

by worik 3y ago

A computer failure. Again. We have been doing payroll for over seventy years. To fail to implement a payroll is a dreadful mistake, and a person is responsible When civil engineers make mistakes like this there is a postmortem and we learn what the mistake was and how not to do it again. Until we start taking responsibility, like real engineers do, computer programmers, we, will continue to let people down like this

abduhl 3y ago
It requires tech to move beyond the standard refrain that this is the manager’s fault. It’s hard to get somebody to accept liability when it can directly hit their pocket book.
- _trampeltier 3y ago
  It is standart exept in the software world.
- ConorSheehan1 3y ago
  Other engineers don't take direct responsibility either. I've never heard of an individual engineer getting sued because a rocket they worked on exploded, or a bridge they built collapsed. Plenty of tech companies do post mortems. This is almost certainly a failure of management. If a single engineer caused this, the process is broken. What the tech industry needs is professional indemnity insurance and competent management.
  - trashtester 3y ago
    Here is an engineer that got sued because a bridge collapsed: https://www.cbc.ca/news/canada/saskatchewan/engineer-designed-bridge-collapsed-facing-discipline-1.6450110 https://www.cbc.ca/news/canada/saskatchewan/engineer-designe... Edit: And here is one from a crane collapsing: https://www.constructionnews.co.uk/health-and-safety/housing-association-and-engineer-sued-over-bow-crane-collapse-06-07-2023/ https://www.constructionnews.co.uk/health-and-safety/housing...
- tremon 3y ago
  But it is the manager's fault: that's the person who holds all the cards in the decision-making process. If you want it to be someone else's fault, then start advocating a different chain of decision making, rather than complain about it being a default refrain.
bravetraveler 3y ago
RCAs have been fairly common in my experience as a systems administrator/SRE/architect Though... I have managed to avoid both startups and government work
victorbjorklund 3y ago
Okay this is probably something that needs a very high level of stability. But many apps/websites arent about life and death. If hackernews goes down no one dies. If a bridge goes down people might die. That is why civil engineering is more regulated (and work takes more time than if it wasnt).
- asveikau 3y ago
  I think programmers can actually misjudge when their bugs are negatively impacting people's lives, especially when they are in the mindset to justify not fixing a bug or improving on a broken design. I've had some experiences working on some popular software, and have definitely seen people trivialize the impact of a bug in ways that do not appreciate that end users are putting the software in the middle of their life, and hence not understanding what it means to the end user when stuff is broken. So a programmer saying "dude relax, it's just a website" doesn't really hold weight to me. To you, a programmer who doesn't want responsibility or hasn't prioritized a bug, it's just a website. To the end user, maybe they are using it in a way you don't expect, they want it to work, and it actually is meaningfully harmful to them when it fails in some way. You can say it's on them for "misusing" your app but ... Again, that's blaming the user for your bugs. A real world example I recall was a colleague who trivialized data loss and reasoned that nobody stores important stuff on that app. The customer complaint was that the "trivial" data that was lost was a recording of his deceased father, or something of the sort.
  - jen20 3y ago
    > I think programmers can actually misjudge when their bugs are negatively impacting people's lives Negatively impacting peoples lives via advertisements is the raison d'être of many software engineering jobs.
  - TheNewsIsHere 3y ago
    > A real world example I recall was a colleague who trivialized data loss and reasoned that nobody stores important stuff on that app. The customer complaint was that the "trivial" data that was lost was a recording of his deceased father, or something of the sort. Wow. I would be beside myself. Ecamm PhoneView is something I used regularly. They discontinued it and suggested moving to iMazing, but it doesn’t contemplate the same use case or workflows, and is a poor replacement albeit very useful and powerful for other uses. This is why I strive to place myself in the customer’s shoes when building and improving something. Don’t take from them, listen to their feedback, let them guide the product within reason, and don’t lose sight of the fact that they’re paying you to work for their interests.
gumballindie 3y ago
> When civil engineers make mistakes like this there is a postmortem and we learn what the mistake was and how not to do it again. We do that in software too. It’s called an agile retrospective. Somehow it leads to more of the same crap. And thats because management usually doesnt allow for proper engineering. They call that getting lost in the details. So then we end up with things failing miserably again and again. But agile books get sold, mckinsey and other bastardisation factories generate profits, and so on.
- abduhl 3y ago
  In civil engineering there is a responsible engineer. Nobody cares what management says - business takes a back seat to public safety, the engineer is in charge. Designs and products are required by law to be backed by an engineer who is personally responsible so the business excuse of “management told us” no longer carries sway: management cannot release a product without a responsible engineer by law so management MUST ultimately be subservient to the math. Software “engineers” cling to their management driven paradigm and resist true accountability and responsibility for engineers because, ultimately, it’s easier and more profitably personally to hide behind the excuse that “management” made the decision.
  - runnerup 3y ago
    > Software “engineers” cling to their management driven paradigm and resist true accountability Yeah just gonna stop you there...none of us were given the choice to be accountable and hide behind "I will lose my license if I commit/deploy this." I'm also an actual engineer in addition to a software engineer, and being able to say "I'm not willing to go to jail for this" works when you have a P.E. license in an actual engineering project, but definitely does not work in the software industry. It doesn't even work in engineering if you don't have a P.E. outside of "No this will literally hurt/maim/kill someone" Yes, either way (software or P.E.) you might be fired for saying "I'm not willing to go to jail for this" but it's much less likely you'd be fired for it in "hard" engineering, because everyone else on the team understands that you're not being entirely hyperbolic when you say "I'm not signing this because I could go to jail." If you said that in a software project people would rightfully think you're fucking nuts and don't understand how the world works, because there's an infinitesimal chance a software engineer would go to jail. Even the criminals who deployed the Uber Greyball thing didn't face any consequences, which truly shocked me, as that was blatant obstruction of justice.
stefan_ 3y ago
Who said the "computer programmers [..] let people down"? "A computer failure" is the rallying cry of middling bureaucrats all over the world because to them it translates into "no one is to blame", used most prominently of course when something is their responsibility. If you can't make payroll with the payroll software, start hand signing checks, but don't blame "the software" and "the computer programmers".

by worik 3y ago

abduhl 3y ago

It requires tech to move beyond the standard refrain that this is the manager’s fault. It’s hard to get somebody to accept liability when it can directly hit their pocket book.

_trampeltier 3y ago
It is standart exept in the software world.
ConorSheehan1 3y ago
Other engineers don't take direct responsibility either. I've never heard of an individual engineer getting sued because a rocket they worked on exploded, or a bridge they built collapsed. Plenty of tech companies do post mortems. This is almost certainly a failure of management. If a single engineer caused this, the process is broken. What the tech industry needs is professional indemnity insurance and competent management.
- trashtester 3y ago
  Here is an engineer that got sued because a bridge collapsed: https://www.cbc.ca/news/canada/saskatchewan/engineer-designed-bridge-collapsed-facing-discipline-1.6450110 https://www.cbc.ca/news/canada/saskatchewan/engineer-designe... Edit: And here is one from a crane collapsing: https://www.constructionnews.co.uk/health-and-safety/housing-association-and-engineer-sued-over-bow-crane-collapse-06-07-2023/ https://www.constructionnews.co.uk/health-and-safety/housing...
tremon 3y ago
But it is the manager's fault: that's the person who holds all the cards in the decision-making process. If you want it to be someone else's fault, then start advocating a different chain of decision making, rather than complain about it being a default refrain.

bravetraveler 3y ago

RCAs have been fairly common in my experience as a systems administrator/SRE/architect Though... I have managed to avoid both startups and government work

victorbjorklund 3y ago

Okay this is probably something that needs a very high level of stability. But many apps/websites arent about life and death. If hackernews goes down no one dies. If a bridge goes down people might die. That is why civil engineering is more regulated (and work takes more time than if it wasnt).

asveikau 3y ago
I think programmers can actually misjudge when their bugs are negatively impacting people's lives, especially when they are in the mindset to justify not fixing a bug or improving on a broken design. I've had some experiences working on some popular software, and have definitely seen people trivialize the impact of a bug in ways that do not appreciate that end users are putting the software in the middle of their life, and hence not understanding what it means to the end user when stuff is broken. So a programmer saying "dude relax, it's just a website" doesn't really hold weight to me. To you, a programmer who doesn't want responsibility or hasn't prioritized a bug, it's just a website. To the end user, maybe they are using it in a way you don't expect, they want it to work, and it actually is meaningfully harmful to them when it fails in some way. You can say it's on them for "misusing" your app but ... Again, that's blaming the user for your bugs. A real world example I recall was a colleague who trivialized data loss and reasoned that nobody stores important stuff on that app. The customer complaint was that the "trivial" data that was lost was a recording of his deceased father, or something of the sort.
- jen20 3y ago
  > I think programmers can actually misjudge when their bugs are negatively impacting people's lives Negatively impacting peoples lives via advertisements is the raison d'être of many software engineering jobs.
- TheNewsIsHere 3y ago
  > A real world example I recall was a colleague who trivialized data loss and reasoned that nobody stores important stuff on that app. The customer complaint was that the "trivial" data that was lost was a recording of his deceased father, or something of the sort. Wow. I would be beside myself. Ecamm PhoneView is something I used regularly. They discontinued it and suggested moving to iMazing, but it doesn’t contemplate the same use case or workflows, and is a poor replacement albeit very useful and powerful for other uses. This is why I strive to place myself in the customer’s shoes when building and improving something. Don’t take from them, listen to their feedback, let them guide the product within reason, and don’t lose sight of the fact that they’re paying you to work for their interests.

gumballindie 3y ago

> When civil engineers make mistakes like this there is a postmortem and we learn what the mistake was and how not to do it again. We do that in software too. It’s called an agile retrospective. Somehow it leads to more of the same crap. And thats because management usually doesnt allow for proper engineering. They call that getting lost in the details. So then we end up with things failing miserably again and again. But agile books get sold, mckinsey and other bastardisation factories generate profits, and so on.

abduhl 3y ago
In civil engineering there is a responsible engineer. Nobody cares what management says - business takes a back seat to public safety, the engineer is in charge. Designs and products are required by law to be backed by an engineer who is personally responsible so the business excuse of “management told us” no longer carries sway: management cannot release a product without a responsible engineer by law so management MUST ultimately be subservient to the math. Software “engineers” cling to their management driven paradigm and resist true accountability and responsibility for engineers because, ultimately, it’s easier and more profitably personally to hide behind the excuse that “management” made the decision.
- runnerup 3y ago
  > Software “engineers” cling to their management driven paradigm and resist true accountability Yeah just gonna stop you there...none of us were given the choice to be accountable and hide behind "I will lose my license if I commit/deploy this." I'm also an actual engineer in addition to a software engineer, and being able to say "I'm not willing to go to jail for this" works when you have a P.E. license in an actual engineering project, but definitely does not work in the software industry. It doesn't even work in engineering if you don't have a P.E. outside of "No this will literally hurt/maim/kill someone" Yes, either way (software or P.E.) you might be fired for saying "I'm not willing to go to jail for this" but it's much less likely you'd be fired for it in "hard" engineering, because everyone else on the team understands that you're not being entirely hyperbolic when you say "I'm not signing this because I could go to jail." If you said that in a software project people would rightfully think you're fucking nuts and don't understand how the world works, because there's an infinitesimal chance a software engineer would go to jail. Even the criminals who deployed the Uber Greyball thing didn't face any consequences, which truly shocked me, as that was blatant obstruction of justice.

stefan_ 3y ago

Who said the "computer programmers [..] let people down"? "A computer failure" is the rallying cry of middling bureaucrats all over the world because to them it translates into "no one is to blame", used most prominently of course when something is their responsibility. If you can't make payroll with the payroll software, start hand signing checks, but don't blame "the software" and "the computer programmers".