From The Silicon Valley iOS Developers' Meetup held at YML in Redwood City, CA on June 11, 2018. Using “Defensive Pessimism” to Build Great Software at YML Adam Talcott, Edward Cessna, and Ramsundar Shandilya, Y Media Labs At YML, we take pride in creating great software as part of our mission to make digital products and experiences which have lasting impact. An important part of our process is anticipating the various scenarios our software may face and taking those scenarios into account from design through deployment and beyond. At YML, we refer to this concept as “defensive pessimism”. After introducing YML, a customer experience design and technology agency with a vision of becoming our clients’ most valued partner, we will dive into defensive pessimism. We will discuss the ramifications for design and review examples of user experiences created with defensive pessimism in mind. We will also cover the resulting architecture considerations and the impact on reliability.

2. Using Defensive Pessimism to
Build Great Software at YML
The Silicon Valley iOS Developers’ Meetup — June 11, 2018

3. 01 Motivating Defensive Pessimism
02 UX Examples
03 Developer’s Guide to Better UX
Agenda

4. Motivating
Defensive
Pessimism

5. http://bit.ly/yml-defensive-pessimism

6. What is Beauty?

7. Photo by Danyu Wang on Unsplash

8. Photo by Václav Pluhař on Unsplash

9. 2016 Ferarri 488 GTB

10. Can Software Be
Beautiful?

11. Some Possible Characteristics of “Beautiful” Software
• Anticipatory
• Aesthetically-pleasing
• Focused
• Frictionless
• Intuitive
• Innovative
• It Just Works
• Makes the difficult easy
• Omniscient

12. “Simple can be harder than complex.
You have to work hard to get your
thinking clean to make it simple. But it’s
worth it in the end because once you get
there, you can move mountains.”

13. The Happy Path
• Things people would mention to others when
describing an app
• What our users will experience the
vast majority of the time (hopefully)
• Sometimes the dominant focus for designers
• Just the tip of the iceberg
Happy Path
What do we call this?

14. https://twitter.com/ronjeffries/status/586902281125232640
Sad Path
!Happy Path
Exception Path
Edge Cases
We-Didn’t-Think-It-
Would-Do-That Path
The Path the User
Ends Up Taking

15. It’s Reality. Our Software Must Support Reality.

16. The Reality of Developing Software In the Wild
Photo by Nik Shuliahin on Unsplash

18. Yes. We Have to Worry About These Things.
• Some events require error handling and recovery:
• Network requests may fail
• Device may run out of memory or storage capacity
• Some events are failures from which we may not be able to recover programmatically:
• Hardware failures
• Changes to external dependencies

19. Robust-By-Design Software
• Considers the existence of these types of scenarios from the beginning
• Does not simply “bolt them on” later
• Provides a fluid, although possibly degraded, experience despite their presence

20. Benefits of Robust-By-Design Software
• More likely to:
• Be of the necessary quality
• Deliver a rock-solid user experience
• Easier to maintain and test
• The code will be better constructed (built from interconnected components)
• Less likely that other developers will cause software to regress
• Less likely to crash or behave in an unexpected manner in the course of operation
• More secure

21. User Experience Benefits of Robust-by-Design Software
• Things will be more fluid
• Errors, when they undoubtedly occur, will be handled smoothly
• App will not unexpectedly jump between screens or display unexpected states
• No blank screens
• No spinners ad infinitum

22. How do we Create Robust-by-Design Software?
• The more we practice this approach:
• The more scenarios will be known to us
• The better we will become at thinking about new scenarios
• No expectation or requirement that we think of every possible thing which can go wrong
• New scenarios may be handled by existing error handling
• New support will be easier to incorporate
• Think about as many of the various scenarios as we can
• This is a skill that software developers must hone

23. We Must Practice
Defensive Pessimism

24. Defensive Pessimism
• Cognitive strategy whose practitioners:
• Work through all the things which could go wrong
• Plan accordingly
• As a result, approach situations more fully prepared
• Benefit from that extra preparation

25. Our software (and the
people using it) will benefit
if we create software
which, from the beginning,
is more fully prepared for
what can go wrong

26. © 2018 YML. All rights reserved.
UX Examples

27. A Story

28. What does this have to
do with mobile apps?

29. Reliability impacts UX

30. Biggest Source of Unreliability?
The Network

31. Network calls always succeed.
The Assumption:

32. Networks are Inherently Unreliable
Success is indeterminate due to:
• Throughput variability
• Non-zero latency
• Topologies changes

33. Network-dependent apps are inherently unreliable.
All UX issues are mobile quality issues until proven otherwise.

34. UX Implications
For the best UX:
• Keep users informed to keep them engaged
• Transparency of behavior instills trust
• Cancellable actions to provide options, other than the
home button

35. Architectural Implications
• User’s actions need to be:
• Encapsulated as application behavior
• Executed timely on behalf of the user
• Cancellable by the user
• Mapped to one or more “business logic” activities
• Command Design Pattern (e.g., ProcedureKit)

36. © 2018 YML. All rights reserved.
Developer’s Guide
to Better UX

37. Maslow’s Hierarchy of Needs
Wi-Fi

38. Maslow as a User
Data / Content
Functionality
Interaction Design
Graphics
UX

39. UX is a Compromise
Business Goals
UX

40. UX is not a one person job

41. How can developers contribute to UX?

42. 01 When stuff takes time, keep the user engaged.

43. Avoid the spinner

45. 02 Predict

46. Most apps
upload hereWe start uploading here

47. 03 Responsiveness

48. Fake it ’til you make it

50. Like Action
Contact
Server
Do Nothing
Regular model
Update UI

51. Like Action
Contact
Server
Do Nothing
Update UI
Revert UI
Optimistic model

52. Defensive Pessimistic
Software
Optimistic UX

53. “This is all your app is: a collection of tiny details.
Getting the details right is the difference between something that
delights, and something users tolerate.”
- Jeff Atwood, CodingHorror | StackOverflow