This is the second blog post inspired (provoked?) by Nobel
Laureate Daniel
Kahneman’s TED
talk on our "experiencing
selves" and our "remembering selves". The first
installment applied his theory to User
Experience (UX) design principles; this installment pivots from a user’s experience of their applications
to an application’s experience of its
users.
Kahneman’s thesis is that our remembering self (that part of
the mind that organizes experiences into stories to be replayed) dominates our
decision making and that our experiencing self (that part of the mind that is
in the here and now and feels things like happiness) has little residual impact
on our decision making. The root cause is evolutionary. Humans
are programmed to re-live the past to better anticipate the future (so that we
survive). So, when we think about the future, we don’t think of our future as
experiences. We think of our future as anticipated stories (anticipated
memories of experiences to be had).
Yet, if we allow our life to be dictated too heavily by these
memories (that are incomplete and all too often inaccurate) – the imbalance
between our remembering and experiencing selves will ultimately extract a huge
emotional, psychic and physical toll.
This explains why practices like yoga are so transformative
and powerful to so many; yoga is all about restoring balance. Yoga is about
being present physically, emotionally and spiritually – yoga is designed to offset our evolutionary programming of re-living
the past to anticipate the future.
An application’s
programming is the polar opposite; an application lives 100% in the
present. An application operates as pure “experiencing self.” At every given
moment during an application’s lifecycle, it is the sum total of its software
state, data values, exception handling, etc.) with no rendition of the past and
no notion of the future. This complete lack of contextual awareness – of always and only being in the moment -
is an imbalance of its own and just as unhealthy as someone who is never in the moment. User experience,
software quality and security gaps are often, at their root, tied to an
application’s poor contextual response in production; the absence of historical
data and heuristics (a remembering self) causes all sorts of problems for an
app and its users – and all sorts of
grief for its creators.
The source of our respective dysfunctions (people and apps) can
be traced to the differences in our respective genesis; people evolve while applications are created. Here’s the rub. Apps may not worry about the success of
future generations (iterations) – but
their creators do! What are the practices
that we, as application creators, can follow to ensure application balance (to optimize
user experience, quality and ROI)?
Question: What is the application analog to yoga?
Answer: Feedback driven development and automated operational response to runtime behaviors.
To bring balance to applications means offsetting an
application's bias to always be in the moment just as yoga offsets our tendency to be
everywhere BUT in the moment. Feedback driven development and the increasingly
automated and sophisticated operational responses to application events
(DevOps) are designed to do just that – to ensure that both production
applications and their future iterations are increasingly responsive and
effective over time.
Now before we go too crazy – lets agree that analogies are
not tautologies (or else we wouldn’t need two different words would we?) so we
can only go so far with something like this – but here’s a little table that
maps this out…
Yoga stuff
|
Development stuff
|
How they line up…
|
Physical, mental and spiritual well being
|
User experience, software quality and development ROI
|
What it is we’re trying to get right (fine tune)
|
Yoga Sutras
|
Agile Methodology
|
An organized approach to restoring balance
|
Hatha Yoga
|
ALM & DevOps
|
The dimension of the practice focused on the real world.
|
Asanas
|
Patterns and practices
|
Pose[s] or pattern(s) you can hold/implement with ease
|
Whether or not your willing to follow me on this yoga analogy - I think the fundamental point is that a balanced development process (and an app with maximum ROI) must make it easier for development to improve future iterations and operations to manage. Conversely, its unhealthy (unproductive) for development to favor its inherent bias - to build applications that merely meet predefined functional specifications; it serves everyone's selfish interests to invest in practices and technologies that connect applications in production to development and operations.
