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

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

6. Why "failure?"

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.

18. Access 2011

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

32. Iteration

33. "Pivots"

34. 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?

35. Lightning talks!