Skip to content

Instantly share code, notes, and snippets.

@john-kurkowski

john-kurkowski/Fault-Tolerance.md

Forked from pixelhandler/Fault-Tolerance.md
Last active October 22, 2015 01:17
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save john-kurkowski/8dce1a7c5922c65a83e0 to your computer and use it in GitHub Desktop.
Save john-kurkowski/8dce1a7c5922c65a83e0 to your computer and use it in GitHub Desktop.
Download ZIP
Fault Tolerance: Software is ruining the human experience
Raw
Fault-Tolerance.md

Fault Tolerance: Software is Ruining the Human Experience

Mostly a rant on a few bad experiences that could have been prevented in real life if engineers did a good job instead of a good enough job. We have no oath to "Do no harm!" So, we take license to ship whatever. This is bad for humans.

Intro: Fault Tolerance and Bad Human Experiences

Pumping Up the Tires

  1. Wow look new technology, pumping up tires is way better now
  2. Not so much, they added software to the process, oops
  3. Pumps and deflates automatically to read pressure
  4. What could go wrong?

I'll show you what went wrong…

  1. pumping-air-1
  2. pumping-air-2
  3. pumping-air-3

Deep Cleaning at the Dentist

  1. Wow look software to manange dental practices cool
  2. Helps patient care?
  3. We ship "good enough" software
  4. We target the Web cause it runs everywhere
  5. What could go wrong?

Let me tell you about how to waterboard dental patients, while you work around the UI bug that prevents dental assistants from inputing data.

  • Everying is so modern now at the dentist, what is missing?
  1. I can't spit
  2. I can't sit up
  3. No one is helping me while I choke
  4. Feels more like torture than I remember it

Craftsmanship and Software Delivery

Hey we need to ship this project now, what can we shave off?

  • A feature or two that is just too time consuming
  • Automated tests cause that takes effort and is not easy

Oh let's add some new features now that beta is in production

  • No time for tests
  • Code gets messy
  • OK to ship with edge cases

We get used to shipping software with known issues, our bad.

We can do better, right?

  • Add tests at the start, during and/or at the end of sprint
  • Capure requirments and edge cases better in wiki, surface the 'Why' our trackers mostly have the "How"
  • Definition of Done (acceptance criteria) to include known edge cases
    • Identify must have for release
    • Include path for users to recover from unsupported edge cases
      • For error conditions that are relevant to the user, never silently fail.

How Can Our Tech Stack Help?

  • Logs, dashboard in splunk
  • Post client errors, log and add to a dashboard

In Ember?

In Rails?

What Does That Look Like?

An example from ember-jsonapi-resources addon:

Better UX

Ultimately, it depends on you to analyze and respect your user's situation, mental model, and cognitive load.

I do have a few universal suggestions though.

  • Don't use window.alert. Avoid modals.
  • Display errors in context.
    • Don't stuff everything into a growl, out of context with where the problem is.
  • Dismissing errors
    • Don't hide messages after a time without a way to retrieve them.
    • Do automatically hide messages as the user moves on with their life.
  • Offer inline retry and help.
    • You can spend engineering time to think of all the edge cases, or support time to field the rare errors.

Toggle with confirm & retry-on-error

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment