How complex systems fail (2002) [pdf]
web.mit.edu
How complex systems fail (2002) [pdf]
1–10 of 22 posts
Re: How complex systems fail (2002) [pdf]
#2This episode is the most relevant, but see the whole series:
Re: How complex systems fail (2002) [pdf]
#3Here it is directly from MIT instead of the cancerous researchgate silo: http://web.mit.edu/afs.new/athena/course/2/2.75/resources/ra... (the 1998 version to be fair but the sole addition seems to be some infographic of the contents)
Re: How complex systems fail (2002) [pdf]
#4The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense against failure role is emphasized. At either time, the outsider’s view misapprehends the operator’s constant, simultaneous engagement with both roles.
So much this. I coach and train my clients (Fortune 500) in extreme programming (unit testing, TDD, CI, CD, etc). The duality these developers live with and managements obliviousness to their own detriment create a toxic and anxiety inducing work environment. It's very upsetting to me how these developers live with the manager/stakeholder constantly breathing down their necks to cut corners and "get it done" meanwhile holding them accountable for any mistakes.
Re: How complex systems fail (2002) [pdf]
#5The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense agains…
>"get it done" meanwhile holding them accountable for any mistakes.
Sorry, is there an area of business that is not like this?
Re: How complex systems fail (2002) [pdf]
#6TL;DR Spend 80% on expensive consultants qualified in "project management method" such as PRINCE2/V-Model and make a f*g nightmare for the people who actually try to make it work.
A picture is worth a thousand words:
https://upload.wikimedia.org/wikipedia/commons/8/8f/Systems_...
Re: How complex systems fail (2002) [pdf]
#7Here it is directly from MIT instead of the cancerous researchgate silo: http://web.mit.edu/afs.new/athena/course/2/2.75/resources/ra... (the 1998 version to be fair but the sole addition seems to be some infographic of the contents)
Thanks, we've updated the link from https://www.researchgate.net/publication/228797158_How_compl....
Re: How complex systems fail (2002) [pdf]
#8This all looks spot on from my experience, except I have this nagging voice in my head that says the methods they are criticizing, seem to be exactly what the airline industry has done for decades in the wake of plane accidents. The result has been an ever-improving safety record, without preventing normal operation; although it is a pain to get through security at the airport, people do in fact continue to get from here to there. So, how do the methods they criticize here, differ from the airline industry's, or if they don't what's the flaw in this analysis?
Re: How complex systems fail (2002) [pdf]
#9The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense agains…
> constantly breathing down their necks to cut corners and "get it done" meanwhile holding them accountable for any mistakes
It's not just cutting corners in the actual implementation, but also the metrics and management infrastructure for post-release operations.
Re: How complex systems fail (2002) [pdf]
#10The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense agains…
jdjebc82747's dead comment:
>"get it done" meanwhile holding them accountable for any mistakes.
Sorry, is there an area of business that is not like this?
It's not that other areas of business aren't like this, it's that management creates an environment where mistakes are more likely (and in some cases almost certain) to happen, and then penalizes people when they happen.
An example: Bosses refuse to provide funding for materials and time to automate the test framework (embedded systems). So testing is done mostly manually, this consumes a great deal of time or tests don't get conducted due to the lack of time or capability (I can't flip a switch 10 times in a second, or at a particular and precise time). So either we don't have enough time to take the test feedback and correct the system, or we never get the test feedback (because some tests aren't done) in order to correct the system. Errors are virtually guaranteed to slip into production if you're operating on either short schedules or complex systems under these circumstances.
Management expects perfect results, but ties the engineers hands too much so that they aren't able to execute effectively, and then blames (and often dismisses) the engineers as a result.