LOSS AVERSION

Loss Aversion & Software Systems

Neil McKinnon
5 min readApr 19, 2019

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” — Dwight D. Eisenhower

Coupling should be, but often isn’t, considered alongside Loss Aversion (i.e. how averse your business is to the loss of a service, or feature). Owners of systems with a tight-coupling to integral services or features, may suffer great financial hardship if those services become unavailable (e.g. whether in the temporal capacity, or something more final, such as partner bankruptcy). Astute businesses identify key services or features they are averse to losing, and either plan for that failure, or deploy countermeasures (by building slack) into the system.

Netflix provide the archetype from a systems perspective, practicing several key aspects of fault tolerance (in their Microservices architecture) to counter Loss Aversion:

  1. They proactively identify failing services, stop/throttle requests to them, and may terminate defective ones.
  2. They apply fallback procedures for underperforming services; e.g. they may present static recommendation content if the personalised customer response isn’t received in a reasonable time-frame.
  3. They intentionally inject faults, or additional latency, in a controlled manner, into their system to learn from it. Whilst this may seem counterintuitive, it actually increases their resiliency.

Consider the following scenario around Loss Aversion.

Let’s say I’m starting a new business venture to provide baking advice and recipes. To market my business, I need the following things:

  • A domain name representative of my branding. Let’s call it blithebaking.com, costing me $5 per month.
  • A website, to advertise my services, offer advice, recipes etc.
  • Business cards. I use these as part of my branding exercise, to hand out to potential customers. Printed on each card are my contact details and website address (i.e. Domain Name).

The coupling might take this form.

Now whilst this represents a very simple case of Coupling, there’s already a few potential failures here. In this case, I’ll focus on the domain name.

Let’s say I’m remiss, and fail to renew my domain name on its renewal date. Several scenarios can play out:

  1. I’m comfortable with the loss (i.e. I’m not averse to the loss, accept it, and move on). In this case I’m loosely coupled to this outcome and can easily recover.
  2. I’m uncomfortable with the loss, but remedial action is available (i.e. I’m moderately averse to the loss). Whilst in this case, I’m tightly-coupled to the outcome, I have recovery options (let’s say I manage to renew the domain name).
  3. I’m uncomfortable with the loss and there’s no remedial action available (i.e. I’m highly averse to the loss).

Let’s say option 3 occurs. I’m remiss, and lose my domain name to a competitor (it’s a popular domain name!). That competitor links their own website to the blithebaking.com domain, which either confuses all my existing custom, or routes them all to my competitor. I’ve drawn up a table of potential outcomes below.

You can see how quickly the combination of aversions can wreak havoc. The key concepts are:

  • How tightly I’ve coupled myself to depend on something else (whether it’s a business card, or custom).
  • How costly (to me) the loss of that dependency is (this need not be monetary).

Scenario 1 is the best in terms of low coupling/dependence. I’ve spent very little on business cards, and I have limited custom at this stage. I might grumble, but I can live with this outcome. Scenario 2 has cost me dearly due to the significant number of customers I had. Scenario 3 is an interesting one. Whilst I have limited custom, my somewhat unorthodox approach of purchasing 100,000 business cards as an up-front investment (a form of stock), prior to validating my business model, has done me a disservice, inflicting a form of self-inflicted Entropy upon myself.

Scenarios 4 & 5 show the worst cases, where my Loss Aversion is at its highest. In Scenario 5 I demonstrate that for the sake of only $5 a month, I’ve inflicted immediate costs in the region of $62,000. But there’s also the unseen, insidious costs to consider here; e.g. note that I haven’t considered the longer-term branding implications. Has it actually cost me hundreds of thousands of dollars?

How the number of customers affects our Loss Aversion falls into the scale category. Large-scale failings concern me more, because of the large disparity between (say) 10 customers, and 1000 customers.

LOSS AVERSION MAY BE SUBJECTIVE

One individual’s perception of Loss Aversion may differ to another, introducing an additional degree of complexity. For instance, whilst I might consider a $15K loss unacceptable, another — with stronger recovery capabilities — may not.

TIME CRITICALITY & LOSS AVERSION

Time criticality (the permanence of the failure) is another consideration.

Temporal failure may be sufficiently disruptive to put your business at risk, and you might want to consider:

What is an unacceptable duration of disruption to your business? Depending upon the situation, it might be seconds, or even days.

Timing. When did the failure occur? E.g. if my sales website fails at 3am one cold Sunday winter morning, I’m probably less concerned than it occurring at 6pm on Black Friday. Alternatively, if a large proportion of my revenue comes through events (e.g. a sports event), then the timing of a failure is crucial.

What’s interesting about my earlier example was that the outcome was — given enough time and foresight — utterly controllable. Most of the problems I found myself in were due to my inability to react, which I’d inflicted upon myself.

Whilst there’s no golden rules around Loss Aversion, that doesn’t suggest we shouldn’t plan; especially when each scenario is unique, complex, and responses may be subjective. The outcome of any decisions made here should feed into discussions around Coupling.

FURTHER CONSIDERATIONS

--

--

Neil McKinnon

Software Consultant, Architect, Developer, LEAN/DevOps, and Leadership enthusiast.