fail4lib

36
Fail4Lib Failing with grace and style... or not. Jason Casden and Andreas Orphanides NCSU Libraries (jmcasden|akorphan)@ncsu. edu

Upload: jason-casden

Post on 15-Jan-2015

1.949 views

Category:

Technology


0 download

DESCRIPTION

A pre-conference workshop at Code4Lib 2013. Facilitated by Jason Casden and Andreas Orphanides.

TRANSCRIPT

Page 1: Fail4Lib

Fail4LibFailing with grace and style... or not.

Jason Casden and

Andreas Orphanides

NCSU Libraries

(jmcasden|akorphan)@ncsu.edu

Page 2: Fail4Lib

Outline

1. Identifying and managing failure2. Failure anxiety!3. Talking about failure4. Lightning talks

Page 3: Fail4Lib

Outcomes

1. I like to think about wrongness and failurea. 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.

Page 4: Fail4Lib

Part 1: Identifying & managing failure

Page 6: Fail4Lib

Why "failure?"

Page 7: Fail4Lib

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

Page 8: Fail4Lib
Page 9: Fail4Lib
Page 10: Fail4Lib
Page 11: Fail4Lib
Page 12: Fail4Lib
Page 13: Fail4Lib
Page 14: Fail4Lib
Page 15: Fail4Lib
Page 16: Fail4Lib
Page 17: Fail4Lib

Hosted by Nina McHale and Chris Evjy, featuring Monique Sendze, Jason Battles, Rachel Vacek, and Steve Teeri.

Page 18: Fail4Lib

Access 2011

Page 19: Fail4Lib

Biz Lit buzz

● Lean startup principles● Failing fast● Pivots● Beginner's mind● Wrongology

Page 20: Fail4Lib

Managing risk

● Building diverse teams● Expecting dead ends● Having fall-back plans● Fault-tolerant schedules● Establishing flexible goals at the start

Page 21: Fail4Lib

Getting myself beat up

Avoiding Schulz's assumptions1) Ignorance assumption2) Idiocy assumption3) The evil assumption

Page 22: Fail4Lib

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?

Page 23: Fail4Lib

Part 2: Failure anxiety!

Page 24: Fail4Lib

Readings1) 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” mentalityShort 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

Page 25: Fail4Lib

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

Page 26: Fail4Lib

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

Page 27: Fail4Lib

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?

Page 28: Fail4Lib

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?

Page 29: Fail4Lib

Part 3: Talking about failure

Page 30: Fail4Lib

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/

Page 31: Fail4Lib

Balancing credibility and flexibility

Certainty is a limited resource early on

This isn't an excuse for poor planning or communication

Page 32: Fail4Lib

Iteration

Page 33: Fail4Lib

"Pivots"

Page 34: Fail4Lib

Breakout 3: Surviving failure, risk, and the unexpected with grace.

● How do you prepare colleagues for unexpected outcomes?

● What is your organization’s 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?

Page 35: Fail4Lib

Lightning talks!

Page 36: Fail4Lib