4 ms·

And then who was really responsible for that bug? The engineer who didn't care to write tests? The QA person who didn't ensure it worked? Or the manager who pus

And then who was really responsible for that bug? The engineer who didn't care to write tests? The QA person who didn't ensure it worked? Or the manager who pushed their workforce to the brink? As we have seen with Volkswagen, it is the bottom of the chain which tends to be blamed.

larnmar 7y ago
Really? I’ve noticed the opposite — people tend to want to blame people at the top, or the whole company, or whoever has the deepest pockets.
- xmprt 7y ago
  Most people want to blame the top but if you go through the legal system, liability will likely be on the bottom rung of the company. If people are personally liable, they will probably need to find their own lawyers and upper management will easily find ways to shift responsibility.
ggcdn 7y ago
If you follow the professional liability model used in other fields of engineering (civil, etc), the buck stops at whoever sealed the report / letter of assurance / drawings / etc). We usually call them the Engineer of Record (EOR) in my field, and they are usually someone at the top. I'm not advocating for that model in software, but it does provide a very transparent way of determining who is responsible. As the EOR, you may not design every member or do every calculation, but ultimately it's your ass on the line. I suspect it also changes your behavior when you know you are the one taking responsibility.
- KineticLensman 7y ago
  The industry I used to work in used an Independent Assurance Reviewer (IAR) role. The IAR signed off a go-no-go review, whose primary content was identification of the risks that the business would incur if it proceeded past a specific review gate. If an IAR failed a review, the business could still proceed, but the responsibility for subsequent failure then explicitly lay with the leadership rather than the engineers / reviewers. This would be rare though, in most cases IAR failures would lead to mitigation of the identified risks. In an ideal case, the IAR was identified at the outset of a piece of work and was then involved throughout the project life cycle (waterfall or agile). Review points included bid release and contract acceptance as well as design and test readiness reviews.

larnmar 7y ago

Really? I’ve noticed the opposite — people tend to want to blame people at the top, or the whole company, or whoever has the deepest pockets.

xmprt 7y ago
Most people want to blame the top but if you go through the legal system, liability will likely be on the bottom rung of the company. If people are personally liable, they will probably need to find their own lawyers and upper management will easily find ways to shift responsibility.

ggcdn 7y ago

If you follow the professional liability model used in other fields of engineering (civil, etc), the buck stops at whoever sealed the report / letter of assurance / drawings / etc). We usually call them the Engineer of Record (EOR) in my field, and they are usually someone at the top. I'm not advocating for that model in software, but it does provide a very transparent way of determining who is responsible. As the EOR, you may not design every member or do every calculation, but ultimately it's your ass on the line. I suspect it also changes your behavior when you know you are the one taking responsibility.

KineticLensman 7y ago
The industry I used to work in used an Independent Assurance Reviewer (IAR) role. The IAR signed off a go-no-go review, whose primary content was identification of the risks that the business would incur if it proceeded past a specific review gate. If an IAR failed a review, the business could still proceed, but the responsibility for subsequent failure then explicitly lay with the leadership rather than the engineers / reviewers. This would be rare though, in most cases IAR failures would lead to mitigation of the identified risks. In an ideal case, the IAR was identified at the outset of a piece of work and was then involved throughout the project life cycle (waterfall or agile). Review points included bid release and contract acceptance as well as design and test readiness reviews.