3 ms·

This reminds me of the Twitter [0]/HN [1] thread by someone trying to argue that the Boeing 787 MAX couldn't be blamed on software engineers, because it was the

by danso 8y ago

This reminds me of the Twitter [0]/HN [1] thread by someone trying to argue that the Boeing 787 MAX couldn't be blamed on software engineers, because it was the aerodynamic/mechanical/systems engineers and business executives who demanded too much (and also, the pilots for just not being better trained). Yes, that's all technically true. We could even put more blame on the human desire for convenient speedy travel as more of a direct factor. But software engineering is part of systems engineering for any modern project. We should want and expect software engineers to have the agency and bigger-picture thinking to do more than just design for inadequate inputs. [0] https://twitter.com/trevorsumner/status/1106934369158078470 https://twitter.com/trevorsumner/status/1106934369158078470 [1] https://news.ycombinator.com/item?id=19414775 https://news.ycombinator.com/item?id=19414775

jdietrich 8y ago
The buck stops with senior management; the buck always stops with senior management. That is the essential lesson of the 5 whys and the essential problem with trying to use it without being fully committed to the Toyota Production System. If senior management aren't willing to cop the blame for literally everything that ever goes wrong, the whole effort is just a dog-and-pony show. https://en.wikipedia.org/wiki/Toyota_Production_System https://en.wikipedia.org/wiki/Toyota_Production_System
- dtech 8y ago
  I disagree. If an outage in the product your team managed was caused by a bug your team introduced 5 can point at several root causes and solutions that your team will be able to control and implement. Management only comes into play when causes like "under-funding", "constantly changing requirements" or "too tight deadlines" are identified.
  - vajrabum 8y ago
    Management also has to support the idea of blamelessness and the costs of investigation and remediation and to participate in reviews. Without that support it may work some of the time but often won't.
  - jdietrich 8y ago
    Management have ultimate responsibility for your team - staffing, training, resources, workload and everything else. If one of those is wrong, it's their fault. The alternative is pure scapegoating. Blaming a team or an individual doesn't get to the root cause - why did that employee underperform, why was that team badly led, why did nobody identify or report these problems until it was too late? The answer might be as simple as "we hired a complete moron", but management have to take ownership of that error if they want to prevent similar errors in future.
    - Darkphibre 8y ago
      Reminds me I need to finish Extreme Ownership. Got about half way through, a really excellent philosophy.
  - bluGill 8y ago
    Management is still at fault for not putting in place enough quality to ensure that the bug didn't happen, or was found first. There are a number of ways to do this. They can spend more time and money testing the product before it goes to production. They can spend more money/time on automated testing infrastructure. They can spend time/money on failover to last good version. They can spend time/money on up front design. They can decide that the costs of any of the above is too high and so they will accept the risk. Depending on your exaction situation any of the above can be most cost effective (often a combination - in particular accepting risk eventually is required no matter how much you spend on something else).
eridius 8y ago
The fundamental point of the argument that software wasn't to blame was that the problem wasn't with the way the software was implemented, but with the way it was specced, and that it was performing to spec, and therefore blaming the software was pinning the blame on the wrong folks as the software folks didn't write the spec (and the people who wrote the spec didn't control the factors that led to the need for the spec, etc). > We should want and expect software engineers to have the agency and bigger-picture thinking to do more than just design for inadequate inputs. Saying software engineers should have bigger-picture thinking doesn't help if the software engineers aren't empowered by management to make the necessary changes.

by danso 8y ago

jdietrich 8y ago

The buck stops with senior management; the buck always stops with senior management. That is the essential lesson of the 5 whys and the essential problem with trying to use it without being fully committed to the Toyota Production System. If senior management aren't willing to cop the blame for literally everything that ever goes wrong, the whole effort is just a dog-and-pony show. https://en.wikipedia.org/wiki/Toyota_Production_System https://en.wikipedia.org/wiki/Toyota_Production_System

dtech 8y ago
I disagree. If an outage in the product your team managed was caused by a bug your team introduced 5 can point at several root causes and solutions that your team will be able to control and implement. Management only comes into play when causes like "under-funding", "constantly changing requirements" or "too tight deadlines" are identified.
- vajrabum 8y ago
  Management also has to support the idea of blamelessness and the costs of investigation and remediation and to participate in reviews. Without that support it may work some of the time but often won't.
- jdietrich 8y ago
  Management have ultimate responsibility for your team - staffing, training, resources, workload and everything else. If one of those is wrong, it's their fault. The alternative is pure scapegoating. Blaming a team or an individual doesn't get to the root cause - why did that employee underperform, why was that team badly led, why did nobody identify or report these problems until it was too late? The answer might be as simple as "we hired a complete moron", but management have to take ownership of that error if they want to prevent similar errors in future.
  - Darkphibre 8y ago
    Reminds me I need to finish Extreme Ownership. Got about half way through, a really excellent philosophy.
- bluGill 8y ago
  Management is still at fault for not putting in place enough quality to ensure that the bug didn't happen, or was found first. There are a number of ways to do this. They can spend more time and money testing the product before it goes to production. They can spend more money/time on automated testing infrastructure. They can spend time/money on failover to last good version. They can spend time/money on up front design. They can decide that the costs of any of the above is too high and so they will accept the risk. Depending on your exaction situation any of the above can be most cost effective (often a combination - in particular accepting risk eventually is required no matter how much you spend on something else).

eridius 8y ago

The fundamental point of the argument that software wasn't to blame was that the problem wasn't with the way the software was implemented, but with the way it was specced, and that it was performing to spec, and therefore blaming the software was pinning the blame on the wrong folks as the software folks didn't write the spec (and the people who wrote the spec didn't control the factors that led to the need for the spec, etc). > We should want and expect software engineers to have the agency and bigger-picture thinking to do more than just design for inadequate inputs. Saying software engineers should have bigger-picture thinking doesn't help if the software engineers aren't empowered by management to make the necessary changes.