
Ironies of Automation  (1983) - jamesbritt
http://www.bainbrdg.demon.co.uk/Papers/Ironies.html
======
gatehouse
This paragraph made me think of the masses of office drones who are performing
repetitive tasks using poorly designed software on inadequate machines:

 _Ekkers and colleagues (19791) have published a preliminary study of the
correlations between control system characteristics and the operators '
subjective health and feeling of achievement. To greatly simplify : high
coherence of process information, high process complexity and high process
controllability (whether manual or by adequate automatics) were all associated
with low levels of stress and workload and good health. and the inverse, while
fast process dynamics and a high frequency of actions which cannot be made
directly on the interface were associated with high stress and workload and
poor health. High process controllability, good interface ergonomics and a
rich pattern of activities were all associated with high feeling of
achievement. Many studies show that high levels of stress lead to errors,
while poor health and low job satisfaction lead to the high indirect costs of
absenteeism, etc. (e.g. Mobley and colleagues, 1979)._

\- incoherent information: PC LOAD LETTER

\- low complexity: Email/Calendar/Address Book, a 12 year old could do it on
pencil and paper

\- low controllability: "Hold on a minute, I'm just waiting for the computer,"
says ever receptionist everywhere

\- poor ergonomics: sitting in a cubicle using software written by the lowest
cost bidder

\- simple pattern of activites: click, click, click, click, click, click,
click

EDIT:

Thus, they do jobs that are seen as easy (low status), with minimal training
and an environment that is hostile to wellness, attentivity, and focus, and
totally outside their control. An environment which directly interferes with
their principal purpose of interacting with people, understanding people, and
using their judgement to help people or the company.

Add to that the common flaw of push-based throughput oriented high-utilization
management, instead of pull-based availability oriented high-output management
.... welcome to the psychic prison.

------
barrkel
It's hard to read about this and not think about Air France Flight 447.

Relevant:

[http://spectrum.ieee.org/riskfactor/aerospace/aviation/air-f...](http://spectrum.ieee.org/riskfactor/aerospace/aviation/air-
france-flight-447-crash-caused-by-a-combination-of-factors)

[http://spectrum.ieee.org/computing/software/automated-to-
dea...](http://spectrum.ieee.org/computing/software/automated-to-death/0)

------
dmckeon
The auto/manual difference seems related to: "debugging is twice as hard as
coding" and argues for a self-driving car model that is fully automatic, and
would pull over and stop if it cannot cope, rather than an assisted/monitored
model that is mostly automatic, except when problems suddenly arise, when it
might toss the intractable issue (and control of a moving vehicle) to a
previously more competent driver. ("Hey, human, it's suddenly snowing, and I'm
losing traction, take the wheel, now!")

------
unexistance
... and this article is apparently less important to HN-ers :D

anyway, this adds more to my belief that our current / future IT 'issues' are
actually have been solved / solvable by the past. It's just that the past are
buried somewhere, either in paper / old machine / brain

------
mantrax5
I'd love to chat with the author of this paper.

This is pure gold, I love the analytical thinking in it, especially as someone
designing systems that commonly interface computers with human operators.

I've saved it, it's a great checklist of unintended effects of design
decisions I can go through while working on my projects.

