Every day create your history…..

…..Every path you take you’re leaving your legacy

Part 4 of my series on Michael Bolton‘s (F)EW HICCUPPS mnemonic.

History. We expect the present version of the system to be consistent with past versions of it.

What is your relationship to change?


Much as my attitude is to the introvert-extrovert spectrum, my feelings about change contrast massively. These attitudes that I hold are not binary, and I believe that I am not unique in this.

But, there is a reason why resting on your laurels is a phrase with negative connotations. In software, this is definitely true, whether we like it or not.

You only need to look at the impact that was made when Microsoft ended support for XP, to see how difficult and irksome it was for businesses and organisations to continue – either by paying for continued support or by migrating older systems to a newer OS, both of which carry a huge cost.

An example can be found at: http://bgr.com/2015/06/24/windows-xp-support-us-navy-millions/

Changes can be both positive and negative, and perceived very differently by the end users. Forum posts are full of suggestions for new features and complaints about changes that have been made, sometimes in direct contradiction of each other.

Public perception of your product can be vital, a big change can be a massive turn off, and competition could be there to capitalise, Apple often being a prime candidate – see http://uk.complex.com/pop-culture/2011/11/tech-companies-dissing-apple-in-commercials/blackberry-flash-commercial

When I started as a games tester in 2004, the title needed to get it right first time.

We live in an age of updates, patches, OTA upgrades and the like. The age of continuous updates was a game changer.


A sudden and big change can be one thing….


….but removing a feature can be worse.

When Chrome 52 came out, the functionality of the backspace key changed and irked a lot of users.

What does that mean for us as testers? How does this change the way that we can advocate for the end user? How are changes communicated? How often are changes delivered?

These will all be things that we need to consider, but there is no blanket answer for these.

As a user I have to accept that change will happen, if I don’t accept updates I will lose functionality or worse still security features (read wannacry).

As a tester, I should have a feel and understanding for my product, when things change are we improving the product for the end user? How often should updates be pushed to production?

The Japanese have a phrase for continuous improvement, kaizen, and that is something that we should bear in mind with our products regardless of domain.


My challenge to you and myself, is to look into how this mindset can be implemented in your own domain.

Blog post title lyrics from: History – Tony Moran’s HIStory Lesson – by Michael Jackson.

Find all the songs from my blog posts at this Spotify playlist.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: