4 ms·

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

> 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.
- gumballindie 3y ago
  > 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. I wish it was that easy. In almost all software companies, with the exception of one where we built software security tooling, management asked for cutting corners, to which engineers objected. Guess who got the blame when things went according to what has been said? The engineers. In one case it was so pathetic that the company lost tens of millions of pounds in revenue. There was a code freeze. Turns out a marketing director _told_ an engineer to apply a change. That change tipped everything over. Fortunately the marketing director was “freed” later on. Similarly in other companies people payments were either processed twice, not at all, accounts lost, user login details mixed or leaked and so on. Every darn time technical debt was raised someone would say that we should not over engineer things. But hey they did agile and unit tests. My invoices got paid. It is what it is.
Waterluvian 3y ago
Yeah. We pretend to do it in software. If the liability isn’t placed legally on anyone’s shoulders, then it’s not actually being done. That’s indeed what makes it easy for management to consciously or subconsciously allow outcomes that do real harm like people not getting paid. There is no incentive not to be a %#^*up. At worst a manager looks bad. But they can always blame the engineers since there’s a system in place, so it couldn’t have possibly been the manager being a %#^*up.
iancmceachern 3y ago
It's commonly done in software in regulated environments, i.e. iso 62304 for medical devices
jjav 3y ago
> We do that in software too. It’s called an agile retrospective. A retrospective is not an incident postmortem, very different things. A retrospective tries to look at how the agile process went wrong again this past sprint, but is not focused specifically about one production incident. Companies should be doing incident postmortems on any incident of significance to identify action items to improve what went wrong on that specific case.
- TheNewsIsHere 3y ago
  Wholeheartedly agreed. A retrospective’s documentation is essentially the smallest opaque piece of what an investigation would draw upon working backward. It happens fairly quickly after the causal factor is introduced and is likely to be completed before the software actually causes harm in production at a scale like this. The results of a retrospective could make for a good source for recommendations, but only if it covered the causal factors.

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.
gumballindie 3y ago
> 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. I wish it was that easy. In almost all software companies, with the exception of one where we built software security tooling, management asked for cutting corners, to which engineers objected. Guess who got the blame when things went according to what has been said? The engineers. In one case it was so pathetic that the company lost tens of millions of pounds in revenue. There was a code freeze. Turns out a marketing director _told_ an engineer to apply a change. That change tipped everything over. Fortunately the marketing director was “freed” later on. Similarly in other companies people payments were either processed twice, not at all, accounts lost, user login details mixed or leaked and so on. Every darn time technical debt was raised someone would say that we should not over engineer things. But hey they did agile and unit tests. My invoices got paid. It is what it is.

Waterluvian 3y ago

Yeah. We pretend to do it in software. If the liability isn’t placed legally on anyone’s shoulders, then it’s not actually being done. That’s indeed what makes it easy for management to consciously or subconsciously allow outcomes that do real harm like people not getting paid. There is no incentive not to be a %#^*up. At worst a manager looks bad. But they can always blame the engineers since there’s a system in place, so it couldn’t have possibly been the manager being a %#^*up.

iancmceachern 3y ago

It's commonly done in software in regulated environments, i.e. iso 62304 for medical devices

jjav 3y ago

> We do that in software too. It’s called an agile retrospective. A retrospective is not an incident postmortem, very different things. A retrospective tries to look at how the agile process went wrong again this past sprint, but is not focused specifically about one production incident. Companies should be doing incident postmortems on any incident of significance to identify action items to improve what went wrong on that specific case.

TheNewsIsHere 3y ago
Wholeheartedly agreed. A retrospective’s documentation is essentially the smallest opaque piece of what an investigation would draw upon working backward. It happens fairly quickly after the causal factor is introduced and is likely to be completed before the software actually causes harm in production at a scale like this. The results of a retrospective could make for a good source for recommendations, but only if it covered the causal factors.