A tale of Bill and Jill

Over the weekend, we lost my great-aunt Jill – she was in her 80s, and thankfully suffered only a brief illness. 

Death is always a time for reflection – and this time is no different. But I'd like to really take a moment to reflect back on her life, as she and her husband Bill influenced me in ways that only death gives us clarity on.

My uncle Bill was related to me on my mother's side. He was my grandfathers younger brother, born into a mining community in Stoke-on-Trent in the 20s. My grandfather is one of the smartest (and most stubborn) men I know, but Bill was academically brilliant, and was offered the opportunity to study at Oxford – almost unheard of for someone from the lower classes at that time. This study he achieved with some financial support from my grandfather.

There Bill met Jill, and they fell in love. But Jill was a spirited woman, and when he asked her to marry him, she turned him down, as she desperately wanted to do voluntary work overseas, and wasn't ready to settle down. She travelled to Africa, which she fell in love with, and did all sorts of educational work with the local tribe, becoming an “honorary chieftan” I'm told.

Bill meanwhile turned to teaching – and taught my father across town. When Jill returned from Africa, they ended up picking up from where they left off, becoming married. Their house was a fascinating place filled with relics from Africa such as tribal masks and a wooden case she'd used in her travels which she gifted to my parents.

They were regulars for our Christmases, which we'd spend at my grandparents. With them both being teachers, they'd arrive punctually at 11am on Christmas Day, and they were so entertaining. We never got toys, only books – typical teachers! I remember Bill being able to be quite funny and yet coerce us into doing things – asking one Christmas if we could find the “stealth function” our Starbird electronic (and noisy) spaceship toy. Such a comment could have irritated, but I remember finding it was funny, and played along. It's no wonder he became a headmaster.

Sadly though he died in his 50s when I was a young teen. It was a tragic death, that shocked us all. When I look back, I feel slightly robbed, as I cannot help think how much I would have loved to talk to him when I was older, when I was going through University, and when I went through teacher-training. I'd have liked that a lot.

Inevitably we saw less of Jill without Bill, but we did still see her. And my grandfather being the person he is kept tabs on his brother's wife, as often as possible. She was always family to him.

They left me with a legacy – I was inspired to give teaching a try because of them (although I didn't end up sticking with it), Jills tales of overseas made me want to try living abroad – which inspired me to take the opportunity to study in Jena, Germany and gave me enough of a taste for adventure to consider travelling from England to New Zealand.

But most of all they left me with a book. When I heard about her death, I immediately thought about a book I'd been given by them on Astronomy. As a child I was fascinated like so many with space and the stars. So they bought me a book on it – it was full of stories of the planets (although Voyager 2 hadn't gone to Jupiter yet), about Skylab and the Apollo program, about how stars worked. It was one of the last books Bill and Jill would give me.

I would read through it time and again, and it would inspire me, and fire my imagination. It fuelled a passion for science, and made me want to study Astronomy, which I eventually did at the University of Sheffield. But even though it became dated - there were later missions which gave more information and better pictures - I kept hold of it. I threw other books away but never this one.

At University I would read some pieces to refresh my mind on the basics, before opening my University books, and putting the mathematical framework around what I'd just read. As a teacher I would look to it to work out how to simplify the detailed concepts I knew so younger minds could digest.

But this weekend I realised that the reason I could never throw it away was the book had inspired me, and reminded me of two people who I loved in my own way.

It seems an odd and maybe failed epitaph for a couple to be summed up as “people who bought me a book”. But not if it's a book that changed your life, not if it's a book that inspired you.

Christmas is coming – do something amazing for someone, and buy them a book!

The last temptation of Pekka Marjamaki …

First off, this is all a bit of fun – so don't take too seriously (or consider me a Satan worshipper) ...

Last night Pekka Marjamaki was on Twitter talking about a Tarot reading he'd had done, and if anyone could interpret for him, so we caught up on Skype to discuss it.

I'm a follower of Jungian psychology, and I believe that inside of us is a subconscious that is trying to guide us as best as possible, and sometimes warn us. Unlike our conscious, our subconscious mind cannot talk to us in words, it lurks below our babbling thoughts and can only make itself aware to our conscious mind through dreams and feelings. Sometimes the subconscious should be followed, sometimes rejected – but as often as possible it needs to be understood.

For me, Tarot is one method I'll use to try and check my subconscious, it's part of my toolbox. I don't believe Tarot predicts the future – but I do feel it allows me to read minds, more specifically my own. This isn't magic, this is psychology. But it's still useful.

To me it works like this – a Tarot card is loaded pictorially with very rich and often complex symbolism. When you look at a card within the context of a reading, there will be an initial reaction to it, that reaction is the whole point. It reveals something to you, if you listen to your own mind.

And so when Pekka told me about the cards, I looked up a picture of each card on Google images, and stuck with the reaction I got from that image. Hence when I say this is Pekka's reading, in truth it's more accurately a reading of myself than Pekka.

Pekka explained that he'd asked for a reading about his software testing career, and three cards had been chosen – past, present and future (which provide the context). Put the cards together with my reactions and intuition and it tells a story … this is what we pieced together …

Past – The Priestess

To me, this card really triggers the ideas of learning and being mentored. The Priestess is an enlightened soul, but she's also a keeper of ritual. If you look, she's following instructions from a “Holy Book”. The book guides and enlightens if read with wisdom. But it also can enslave and control withing a prison of conformity we're not allowed to challenge.

This to be really talks volumes about many of our pasts in testing. We learn the secrets of testing, but testing can become an instruction manual – you know, just follow the script in the Holy Book.  For a good few testers, this is all it becomes, slavish routine.

Present – The Magician

Whereas the Priestess follows the book of instruction, the Magician in this picture feels different. This feels like an individual who is in tune with the nature of things. The scroll in his hand is not something he's slavishly followed. It's knowledge he's gained with his own insight, it belongs to him, but he rules that piece of paper and its contents, not the other way around.

This does feel, especially in the context of it's position in the present like someone who has evolved. They have listened to the Holy Book as a Priestess, and they've taken the next step. They don't need the book anymore, they've taken that knowledge, and become attuned to the nature of testing. It is this enlightenment from within and from their observations which now guides them.

In many ways they have become a thought leader.

Future – The Devil

This is a complex one, but as you'd expect, The Devil denotes temptation.

If you look back to the present where The Magician denotes a thought leader, this denotes all the ways we can fall from the path. Perhaps its a desire to in some way “sell out” about testing - not because we want to, but because either there's something to gain, or perhaps because championing testing can feel too hard at times.  We might know how testing works, but go along with following a test strategy as outlined by someone else, even though we know it won't work.

Elisabeth Hendrickson's article Why I Won't Go Back was very much in my mind with this card (not surprising, I'd read it earlier that day). And in it she talked about how sometimes under pressure as testers we'll go along with Cover-Your-Ass activities on projects, which we know won't help the project, and deliver little real value. But we do them out of fear or because we feel it's expected, and somehow we feel our performance and contribution will be seen better if we follow what non-testers expect.  The one that came to mind for both myself and Pekka was “following an ISTQB policy, when we see little real value in it”.

Both me and Pekka, found it an interesting conversation, and these themes (unsurprisingly) really resonated with both our experiences in testing. For me the card about the future really reinforces the responsibility we have when we become enlightened testers not to sell testing short, because it damages the whole community when we do.

Notice in the picture above - once we give into the Devil, it makes slaves of us all!

* For the record, no animals were sacrificed during this consultation.  However when I look at Pekka's current profile picture on Twitter, I do wonder what he's doing to that chicken ...

Oh brother ... it's change management ...

I was really pleased to get such positive feedback on my article yesterday on testing proposed changes before they hit production. But special mention has to go to the following insight from Simon Talks, who is not only my brother, but a very successful Change Manager who is based in Sheffield, England ...

Hey Bro!

There is considerable value in what we term the pre-production environment.

The pre-production environment for us follows all the restrictions of the production environment and devs have no access it (as they should with production!!!).

For changes planned for production there is always a dry run on pre-production and some testing is ran against the pre-production environment.

Far more changes fail in pre-production even if they run in the development and test environments, due to complications in parallel development that usually enable releases to work that wouldn't work in the production environment.

Testing the process of change ... lessons from HMS Invincible

Back in 2003 I worked for a company who provided the software used on the shipboard servers of the Royal Navy. The servers were used as an information network to share important documents between ships around the world. Surprisingly rather than all being top-secret intelligence, most of this was housekeeping. A naval ship essentially share many characteristics of an office, with a large number of people aboard who need to share information on activities, events, usage of disposables (you'd not be too pleased if your office ran out of coffee or toilet rolls), it is in many ways a floating community, and the Naval intranet allowed the organisation of many aspects of daily life.

I was a developer at the time, and following a course had been working (initially at home) on a Perl script which I got my managers permission to pitch to our customer. I'd written my application from scratch, but today we'd recognise many of it's attributes as a shipboard-Wiki (I called it the Generic Web Page, having never heard of Wikis at the time). It allowed sharing of information pages (which could be instantaneously modified by users with suitable permissions) between both personnel onboard ship as well as between other ship servers. Whereas before ships saved and exchanged information in document form (which took time to replicate on the Naval intranet), my ship-Wiki could be updated instantaneously.

The Navy were impressed. Although it was in their opinion not suitable for anything secure, it had a lot of potential uses due to it's speed over the document sharing method that was in use. They wanted to try it out in an upcoming NATO exercise onboard the UK flagship for the exercise, HMS Invincible.

Of course management was delighted to get such an enthusiastic customer response. But they had a fear – could I install my Generic Web Page application safely onboard the Invincible server? This was their dilemma … if I got this application working, it would be a huge statement about our companies can-do attitude. And if it worked well, we had all kinds of ideas to expand the product and provide more of these kinds of applications as a whole new line of work.

However if something should go wrong – then we risked knocking out the information sharing ability of the Royal Navy flagship in what was likely to be a billion dollar joint-forces exercise. The Royal Navy would look bad in front of it's NATO partners, and we would look unbelievably incompetent to our customer.

Risk and gain – all change has elements of both. What was decided, we took a replication of HMS Invincible onto a spare server, and we rolled our change on, we ran the server for a day. Then we rolled the change off, and checked we'd removed it.

We did this to develop a list of steps to apply the change, and to confirm we were drilled in it's use and application, but mostly to check and explore for any potential issues we might have. We wanted no room for error – so we did this in total of 4 times. Then on the 5th day, we used our steps on a completely different server to make sure there were no other potential surprises (unexpected configuration perhaps).

We produced a report, and our Naval adviser was satisfied we'd taken adequate precautions, so we were allowed to install on the HMS Invincible herself. That was quite an experience to get in the field and perform this change – amazing to be in the belly of such a grand titan. Did you know the ship has a small supermarket called the NAAFI inside that sells soft drinks, chocolate bars etc? Yes the ship has more people and shops than some villages I've lived in!

The installation was a success, and the software proved itself within the exercise. The Navy decided it wanted to develop that kind of capability, so the piece of work was extended to a much bigger program, although I didn't continue to develop on that project.

Testing the process of change

In testing we get quite used to our test environment – during the course of testing it undertakes so many changes and tweaks to get things right. Sometimes it's new builds (which are easy to track under configuration management), sometimes though there's a setting tweak that a developer tries which perhaps they made but forgot to write down.

At the end of testing, you produce an exit report which signs off that what is in your test environment has been checked, and seems acceptable for production.

But how do you confirm the change outlined for production will produce an environment which echoes the one you've signed off? For most releases to new systems, it's usually not a new build that's applied, but a series of changes just to modify elements of your applications and settings.

How can you test that your release team has all the changes needed for production? Well our enterprise on the HMS Invincible was a good start. Start with an environment under test which mirrors production, apply your changes, and test the end result as you would a production verification test. Then roll back, and confirm your changes have gone. Encourage the change team to repeat this process under as production-like conditions as possible (especially regarding timescales). Are any services interrupted during the change? Do any defects encountered during testing seem to come back (that is, you've missed a change somewhere)? Can you do the core, high value actions? Can you effortlessly roll back? Have you developed a definitive list of steps and actions that work every time?

It's amazing how many times we take for granted that what we sign off in our acceptance test environment will be delivered to production. Is your project making steps to ensure nothing's been missed?