The Curse of Remembered Pain

Barring a few unusual individuals, all of us are very good at remembering moments of pain. For the most part, these memories serve us well, helping us to avoid danger and make good judgements. Sometimes, though, remembered pain can blind us to changed circumstances.

Like most people, I have some significant memories triggered by strong pain.

One memory is the long walk home with a damaged bicycle after a particularly acrobatic self-inflicted crash, blood dripping from various grazes and other minor wounds, a nasty impact headache throbbing away and the entire world blurry from the loss of my glasses.

Another is the emotional transition, from smug jokester to abject terror, that showed on the face of a fellow high school student when he realised that the peculiarly male injury he inflicted on me (from behind, with a hockey stick) had backfired in spectacular fashion.

Both of these memories represent learning experiences - and they shaped my behaviour afterwards. The first of these memories tempered my bike riding for some time - though I did eventually manage whatever trick it was that I was attempting. The second taught me some things about who to trust, or not.

There is a point, though, where remembered pain becomes a problem in its own right, distorting our world view and limiting our choices.

In the world of technology, remembered pain can be both a blessing and a curse.

Many of us have the good habit of saving our work regularly, committing our changes to disk to ensure that our work is not lost. For all too many of us, this good habit stems from our experience of the pain of having to spend hours to retype a major essay because the computer crashed before it was saved.

Too often, though, remembered pain is used to make poor decisions.

Some examples …

• the many (vocal!) people who had bad experiences with the early beta pre-releases of Windows Vista - problems caused by poorly written drivers and incompatible software - who still rant and rave about the poor Vista experience even though the vast majority of their issues have been thoroughly addressed in the last 24 months.

• software development teams who don’t use any source code control software because, years ago, one of the senior developers lost some code (through his own misunderstanding) and decided that all source code control products were a waste of time.

• a team lead who would always insisted that the first step in debugging any problem is to do a full rebuild from the command line, because his formative days as a developer were spent working with a C++ compiler whose incremental builds were unreliable. Never mind that the team is working with Java and C# and the compilers are much (much!) better quality.

I’m sure I could extend this list from three to a dozen examples without too much effort, but I think I’ve made my point.

Don’t let remembered pain goad you into making poor decisions.

The key is to test your assumptions - always check to see if they are still relevant.

• If you’re going to write a critical rant about the Windows Vista experience, don’t assume that a fully patched system with the latest drivers will have all the same bugs as the pre-release beta you tried two years ago. Do your audience the courtesy of having run the tests yourselves on a fully patched system with the latest drivers. If you then find a problem, then by all means rant way. But do your homework first.

• If you had a bad experience with a particular version of one product, don’t assume that all products in that product space are equally bad. Do some research (Google is your friend) find out about other peoples experiences.

• Always review your practices and judge whether they are returning value that exceeds their cost. If the assumptions behind a practice are no longer true, discard the practice.

Before you make a decision, review your reasons and motivations. Is your thinking distorted by remembered pain? Is that pain still relevant, or has it already been mitigated?