際際滷

際際滷Share a Scribd company logo

Fail4Lib

Jason Casden
Jason Casden

This document summarizes a workshop on failing with grace and style. The workshop covers identifying and managing failure, dealing with failure anxiety, and talking about failure. It includes readings on software project failures, learning from mistakes, and conducting blameless post-mortems. Participants discuss understanding failure in their work, avoiding problems like the Therac-25 disaster, and surviving failure with grace through preparation, iteration, and appropriate risk management and language. The goal is to think productively about failure and improve how organizations handle, discuss, and learn from mistakes.

1 of 36
Downloaded 10 times
Fail4Lib Failing with grace and style... or not. Jason Casden and Andreas Orphanides NCSU Libraries (jmcasden|akorphan)@ncsu. edu
Outline 1. Identifying and managing failure 2. Failure anxiety! 3. Talking about failure 4. Lightning talks
Outcomes 1. I like to think about wrongness and failure a. Can we talk about it in a productive way? b. Can we improve the ways we handle, seek, or discuss failure? 2. Is this kind of workshop useful? a. There will be a survey.
Part 1: Identifying & managing failure
Readings 1) The Long, Dismal History of Software Project Failure (Coding Horror) http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of- software-project-failure.html 2) Sowing Failure, Reaping Success (New York Times) http://learning.blogs.nytimes.com/2012/05/07/sowing-failure-reaping- success-what-failure-can-teach/ 3) On Being Wrong (Kathryn Schulz via TED) http://www.ted.com/talks/kathryn_schulz_on_being_wrong.html
Why "failure?"
Some flavors of failure Technical failure Failure to effectively address a real user need Overinvestment Outreach/Promotion failure Design/UX failure Project team communication failure Missed opportunities (risk-averse failure) (!) Failure to launch
Fail4Lib
Fail4Lib
Fail4Lib
Fail4Lib
Fail4Lib
Fail4Lib
Fail4Lib
Fail4Lib
Fail4Lib
Hosted by Nina McHale and Chris Evjy, featuring Monique Sendze, Jason Battles, Rachel Vacek, and Steve Teeri.
Access 2011
Biz Lit buzz Lean startup principles Failing fast Pivots Beginner's mind Wrongology
Managing risk Building diverse teams Expecting dead ends Having fall-back plans Fault-tolerant schedules Establishing flexible goals at the start
Getting myself beat up Avoiding Schulz's assumptions 1) Ignorance assumption 2) Idiocy assumption 3) The evil assumption
Breakout 1: Understanding and dealing with failure in your own practice What are the symptoms of failure? How do you identify an incipient failure and try to recover/adjust? What do you do after a project has failed? How do you make failure valuable? (Post-mortems, recovery, etc....) How do you plan for the unknown when beginning a project? How do you manage risk to mitigate potential damage when undertaking work in new areas?
Part 2: Failure anxiety!
Readings 1) Mitt Romney learns the hard way: mission critical systems are called that for a reason (Ars Technica) http://arstechnica.com/information-technology/2012/11/inside-team-romneys-whale-of-an-it- meltdown/ 2) The Therac-25 disaster: the dangers of a nothing will go wrong mentality Short version (CalPoly software engineering): http://users.csc.calpoly. edu/~jdalbey/SWE/Papers/THERAC25.html Full report (Nancy Levison, PI of the Therac-25 investigation) -- Optional, but a fascinating read: http://sunnyday.mit.edu/papers/therac.pdf 3) How risk averse is too risk averse? Bruce Schneier on "Cover Your Ass" security policy (Wired) http://www.wired.com/politics/security/commentary/securitymatters/2007/02/72774? currentPage=all
1: ORCA and contextual testing Testing dimensions for realtime services Communications strategy, training, etc Resource deployment Security, trust, timing, identity mgmt Helpdesk support Common-sense documentation management
2: THERAC-25 & software control Risk management and risk severity High-risk software dev anti-practices Inherited software, new hardware Poor code design and management Redundant hardware checks? Test environment / reality mismatch Limits and risks of software control Opaque error reporting Denial
3: TSA CYA Hindsight-based security practices Relative risk versus perceived risk "Just in case" thinking Visible but ineffective "security theater" What drives risk management decisions?
Breakout 2: Where's the sweet spot? How could these problems have been avoided, or their damage mitigated? How can we manage the need for assigning blame? How do we focus on moving forward after a failure? Are there cases where finding a responsible party is warranted? What liabilities are associated with too great a focus on blame/responsibility? What liabilities are associated with setting aside the assignment of responsibility? What are the worst case scenarios for your own work? How does this affect your risk management choices?
Part 3: Talking about failure
Readings 1) James Dyson on living a life of failure (37 Signals) http://37signals.com/svn/posts/408-james-dyson-on-living-a-life-of-failure 2) Quantity always trumps quality (Coding Horror) http://www.codinghorror.com/blog/2008/08/quantity-always-trumps- quality.html 3) Blameless PostMortems and a Just Culture (Etsy: Code as Craft) http://codeascraft.etsy.com/2012/05/22/blameless-postmortems/
Balancing credibility and flexibility Certainty is a limited resource early on This isn't an excuse for poor planning or communication
Iteration
"Pivots"
Breakout 3: Surviving failure, risk, and the unexpected with grace. How do you prepare colleagues for unexpected outcomes? What is your organizations approach to risk and failure? Is risk well-tolerated/well-managed? What are the consequences of a failed project? Is failure seen as an endpoint -- a negative outcome to an endeavor -- or merely a step in the development process? How do you talk about failure with your colleagues? Supervisors? Stakeholders? Patrons? Reports? What kind of language do you use?
Lightning talks!
Fail4Lib

More Related Content

Fail4Lib

  • 1. Fail4Lib Failing with grace and style... or not. Jason Casden and Andreas Orphanides NCSU Libraries (jmcasden|akorphan)@ncsu. edu
  • 2. Outline 1. Identifying and managing failure 2. Failure anxiety! 3. Talking about failure 4. Lightning talks
  • 3. Outcomes 1. I like to think about wrongness and failure a. Can we talk about it in a productive way? b. Can we improve the ways we handle, seek, or discuss failure? 2. Is this kind of workshop useful? a. There will be a survey.
  • 4. Part 1: Identifying & managing failure
  • 5. Readings 1) The Long, Dismal History of Software Project Failure (Coding Horror) http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of- software-project-failure.html 2) Sowing Failure, Reaping Success (New York Times) http://learning.blogs.nytimes.com/2012/05/07/sowing-failure-reaping- success-what-failure-can-teach/ 3) On Being Wrong (Kathryn Schulz via TED) http://www.ted.com/talks/kathryn_schulz_on_being_wrong.html
  • 7. Some flavors of failure Technical failure Failure to effectively address a real user need Overinvestment Outreach/Promotion failure Design/UX failure Project team communication failure Missed opportunities (risk-averse failure) (!) Failure to launch
  • 17. Hosted by Nina McHale and Chris Evjy, featuring Monique Sendze, Jason Battles, Rachel Vacek, and Steve Teeri.
  • 19. Biz Lit buzz Lean startup principles Failing fast Pivots Beginner's mind Wrongology
  • 20. Managing risk Building diverse teams Expecting dead ends Having fall-back plans Fault-tolerant schedules Establishing flexible goals at the start
  • 21. Getting myself beat up Avoiding Schulz's assumptions 1) Ignorance assumption 2) Idiocy assumption 3) The evil assumption
  • 22. Breakout 1: Understanding and dealing with failure in your own practice What are the symptoms of failure? How do you identify an incipient failure and try to recover/adjust? What do you do after a project has failed? How do you make failure valuable? (Post-mortems, recovery, etc....) How do you plan for the unknown when beginning a project? How do you manage risk to mitigate potential damage when undertaking work in new areas?
  • 23. Part 2: Failure anxiety!
  • 24. Readings 1) Mitt Romney learns the hard way: mission critical systems are called that for a reason (Ars Technica) http://arstechnica.com/information-technology/2012/11/inside-team-romneys-whale-of-an-it- meltdown/ 2) The Therac-25 disaster: the dangers of a nothing will go wrong mentality Short version (CalPoly software engineering): http://users.csc.calpoly. edu/~jdalbey/SWE/Papers/THERAC25.html Full report (Nancy Levison, PI of the Therac-25 investigation) -- Optional, but a fascinating read: http://sunnyday.mit.edu/papers/therac.pdf 3) How risk averse is too risk averse? Bruce Schneier on "Cover Your Ass" security policy (Wired) http://www.wired.com/politics/security/commentary/securitymatters/2007/02/72774? currentPage=all
  • 25. 1: ORCA and contextual testing Testing dimensions for realtime services Communications strategy, training, etc Resource deployment Security, trust, timing, identity mgmt Helpdesk support Common-sense documentation management
  • 26. 2: THERAC-25 & software control Risk management and risk severity High-risk software dev anti-practices Inherited software, new hardware Poor code design and management Redundant hardware checks? Test environment / reality mismatch Limits and risks of software control Opaque error reporting Denial
  • 27. 3: TSA CYA Hindsight-based security practices Relative risk versus perceived risk "Just in case" thinking Visible but ineffective "security theater" What drives risk management decisions?
  • 28. Breakout 2: Where's the sweet spot? How could these problems have been avoided, or their damage mitigated? How can we manage the need for assigning blame? How do we focus on moving forward after a failure? Are there cases where finding a responsible party is warranted? What liabilities are associated with too great a focus on blame/responsibility? What liabilities are associated with setting aside the assignment of responsibility? What are the worst case scenarios for your own work? How does this affect your risk management choices?
  • 29. Part 3: Talking about failure
  • 30. Readings 1) James Dyson on living a life of failure (37 Signals) http://37signals.com/svn/posts/408-james-dyson-on-living-a-life-of-failure 2) Quantity always trumps quality (Coding Horror) http://www.codinghorror.com/blog/2008/08/quantity-always-trumps- quality.html 3) Blameless PostMortems and a Just Culture (Etsy: Code as Craft) http://codeascraft.etsy.com/2012/05/22/blameless-postmortems/
  • 31. Balancing credibility and flexibility Certainty is a limited resource early on This isn't an excuse for poor planning or communication
  • 34. Breakout 3: Surviving failure, risk, and the unexpected with grace. How do you prepare colleagues for unexpected outcomes? What is your organizations approach to risk and failure? Is risk well-tolerated/well-managed? What are the consequences of a failed project? Is failure seen as an endpoint -- a negative outcome to an endeavor -- or merely a step in the development process? How do you talk about failure with your colleagues? Supervisors? Stakeholders? Patrons? Reports? What kind of language do you use?