Farewell to my beloved grandma

Grandma's surprise visit to us when we were on holiday in Wales

In a way, I'm a very lucky man to be here in my forties and only just now having to deal with the death of my beloved grandmother in the last month.  But to be honest, I was a fortunate person indeed to have her in my life, regardless of the duration.

She was such an important person in my life, that much has never been in doubt.  However, the flood of memories that her passing brings gives time to reflect on my time with her, and the influence she leaves still to this day.

As a kid, going to spend the weekend with my grandparents was always an exciting adventure.  It was only an hour in the car, but it seemed an epic journey.  She would always be there to great us on our arrival, always smiling and ready with a gigantic hug and kiss for each and everyone of us.

She's always have something for me.  This was where the excitement began.  There would be a couple of cardboard boxes, some scissors, some pens and all the tape I could ever need waiting for me in the kitchen/dining room.  Each time the boxes would be different ... I looked through them, and when I had some ideas, would get to work.

That pile of cardboard and tape could be fashioned into anything my imagination desired.  Sometime it was a helmet, sometimes a garage for my toy cars, or secret space base for my Star Wars figures.  The possibilities were endless.  It was exhausting work, and thankfully there would be a glass of milk and some Animal Crackers for me when I needed a break.

Grandma loved to watch me at work, and for me to show her all around my inventions.  As I was at work, so was she cooking usually the some stew for our tea in her pressure cooker.  Grandad usually worked Saturdays, and when he came in from the pit, I'd start to tidy up, as we got ready for dinner, taking out the folding table putting the cloth over and setting places.

Grandad liked to joke that Grandma wasn't a great cook, and I'm ashamed to say he was right.  The stew would often be overcooked and over-peppered.  It was years before I realised that brussel sprouts weren't supposed to be yellow!  There was all of us, and often my Uncle Melvin, occasionally with his "girlfriend" Sarah (now his wife).

After dinner, Grandad would put on a record, and get to work on the dishes.  Then we'd drive the car to a nearby garage, walking back to the house with him.  Then on to the evenings entertainment - usually first would be a slide show with Grandad manning the projector, and maybe even with a reel of film.  Without doubt my favourite would be one where we'd gone to see a Wombles carnivale (and the story would always go that I had tried to run away with Madame Cholet).

After that, Grandad would power up the electronic organ - usually we'd be allowed to take one of the books of music and have a go on it.  Afterwards, he'd play and sing for us.

More than anything, my grandparents house was one filled with music.  Neither of them did anything without it being worthy of a song.  Grandma sang when she was a cook (thankfully we was a better singer than a cook), Grandad sang as he did the dishes (and he has one of the most impressive tenor voices I've ever heard), there were records like The Great Carouso being played or the organ recital.

In many ways being at my grandparents felt like living inside a musical.  You know when people say "the problem with musicals is that no-one would just break into song like that" ... well they did at my grandparents house.

All too soon, it would be time for bed, and me and my brother would willingly go up, squeezing into a single bed.  We'd go willingly, as Grandma always came with us, and we weren't really going to bed.  It was story time.  We'd squeeze into bed with Grandma, and she'd read us a book (often one of the Caspar books).  Then it was our turn.  Me, my brother and grandma would take turns telling each other stories - she'd keep asking "and what happened next".

Sunday mornings would start with me and my brother joining Grandma and Grandad in bed for hugs.  I remember always being fascinated by Grandma's dresser which included a recess surrounded by mirrors.  If you looking inside, there was a corridor stretching out to infinity in each direction.

A little like this

[It moved me that when my son was three, he was as fascinated as me by this dresser, but insisted that the mirror boys on the left "were naughty"]

We'd go down to start on getting breakfast ready.  Grandad would shave in the kitchen, singing as always, and filling the house with the smell of Old Spice, before ringing work, to get the status of the pit.  We'd then sit down to tea and oatcakes with cheese.

I'd sometimes cry, because I never wanted to leave.  I just wanted them to live next door to us, and see them every day.  They never spoiled us, except with attention.  Sometimes the people you love the most are those that just give you the tools, the space and the support to be creative.

That's just a slice of who my Grandmother was to us, but an important one.  She was the one who always encouraged us, always loved us, always was wowed by every invention and story.  And that love was unconditional - my mother said of us that we could be found by the police with a bloody knife standing over someone, and she'd go "they've got the wrong person".  Her love and faith especially in me was absolute - and I hate to say it, but as a teen or a young adult, I was unworthy of it.  But here's the thing about a love like that, if it's rare and unusual, you know how precious a thing it is.  And though you are unworthy of it, when you realise just how rare it is, you spend the rest of your life trying to make yourself worthy of it, even beyond death.

The week before I married in 1997, she was diagnosed with the early stage of Alzheimer's.  My funny, always slightly ditsy Grandmother became a little bit more eccentric each year.  But I learned how fragile her life was, and how important in the scheme of things a simple "I love you" could be.  I treasured every moment, such as walking arm in arm with her after my wedding, or the time we took my son to first visit her.  She fought hard, but in 2003, she needed to go into a care home.

Piece by piece, the Alzheimer's took her away.  From 2005 it was impossible to hold a conversation, then she could only recognise Cameron (thinking he was me).  It was heart-wrenching to loose her slowly.  Even when I last saw her, she was unable to do much but hold my hand.  But as she did so she sang, it was the smallest sign that despite everything that Alzheimer's had taken, the smallest piece of her remained.

And through it all the time was Grandad, he visited her every day.  People will tell you the greatest love story you'll ever know was Romeo and Juliet or even Kanye West and Kim Kardashian.  But to me it's my Grandad and Grandma.  Whatever Alzheimer's took, he never forgot who she was, visiting her every day and always felt blessed that she was his, on their 60th Wedding Anniversary describing himself as "the luckiest man in the world".  On their 50th Wedding Anniversary he made this clear to all, singing to her The Anniversary Song in a crowded restaurant, forcing all into stunned silence by the power of his voice, and reducing many, including myself to tears (I told you he was good).

It is only appropriate that as she breathed her last, he was at her side.  Holding her hand.

For a couple for whom music was such an important piece of their life, the music chosen for her funeral was faultless ..

Nat King Cole - Unforgettable

The happy couple - at the beginning

My grandparents with my son

At their 50th wedding anniversary

Their 60th wedding anniversary

Dare to be different ... take risks

Back in 2009 we managed to get to see a William Shakespeare's Midsummer Night's Dream by final year students at Toi Whakaari drama school.  It was a seriously impressive production, which moved the action into a circus setting, with the faerie characters all imagined as unearthly carny folk, giving the actors the platform to learn and display various circus skills.

This year when we found out they were running a production of As You Like It, my 16 year old son was adamant we get tickets.  And let me just say, that's unusual for a teenage boy to go "oh, I really want to watch Shakespeare".

The action started in the basement theatre of Toi Whakaari dressed as the mighty halls of power of some great Dukedom - there is an estranged brother, starcrossed lovers, a comic relief fool and a tyrannical Duke.  Okay, so far so normal for both a Shakespeare production and your average Game of Thrones episode.

It doesn't take too long before everyone is banished from the kingdom on pain of death - it's a good thing Shakespeare never created this character (well it would have made for a shorter play) ...

It's at this point that things not only got odd, they got outright surreal.  It was time for a change of scenery (I know the play well enough to know that).  I have worked on enough amateur dramatic pieces to know this is usually the point where a load of burley folk such as myself, dressed in black, come on-stage to do the silent ballet that occurs when a scene change.

But it didn't happen.  Instead, silently, out came the fool from the story, pulling a curtain at the back of stage, then unbolted one door, and then another.  There was something behind the stage, an eerie lit corridor, leading to something uncertain.  At this point someone far beyond started singing (beautifully I should add), and we the audience were ushered from our seats, through and beyond.

We just didn't know what was going on, but we soon would.  Instead of a scene change, we joined the principles in exile, being moved into a second theatre behind where the rest of the play would take place.

Photos courtesy of Toi Whakaari, photographer Philip Merry (thanks guys)

Typically the rest of the play takes place deep in the forest, but here the scene and characters were imagined as some Kiwi hippie commune.  There was a lot of fun to be had seeing some of Shakespeare's characters re-imagined as a variation of the kind of people you'd bump into at the local hipster cafe, or on an Annabelle Langbein/Country Calendar episode.

Of course all these twists and customisations can be dismissed as gimmicks if the play itself isn't very good, or poorly acted.  As with Midsummer Night's Dream we walked away feeling we'd got a professionally produced play "on the cheap", and indeed there was the "hard to pull off" achievement of making a 400 year old play so exciting to a teen veteran of XBox that he wants to know if we can see again.  That's no small undertaking!

As per usual though, this isn't just a "review of a great play", but there are some really key themes here that echo with life in the office.  There are a lot of oddities and gambles at play here,

• Switching theatres mid-play
• The commune setting and Kiwi-isation of characters
• As usual with Toi Whakaari, it's a very intimately performed play, with actors sometimes not just making direct eye contact as they deliver a line, but also instead of going off stage will sit in with the audience in character.  This always gives this odd, surreal experience that you are not so much watching a play as sitting within it.  Such things are not for the faint hearted!

If this was a full professional production, there would be the temptation to cut a lot of that out - a bigger, theatre means more bums on seats, and more money yes?  And while we're at it, maybe we should curb back a few of our ideas, and make it more "as per expectations" for Shakespeare, right?

What's so interesting about both productions we've seen at Toi Whakaari is that there is an awful lot of passion on show, but also an awful lot of gamble.  And that's risky - in fact from this theatre piece from our paper it seems there was reviewer who disliked it as much as we loved it "muddled ... there are too many distracting moments from the main scene" and "what is missing is the sense, made explicit in the play, 'of the golden world', whether it was in classical Greece or Robin Hood's merrie England".

Unfortunately that reads like "why isn't it like every other production of As You Like It".  That gives a sense that the play that's performed today should be exactly as performed 400 years ago, with no new-fangled electric lights, or seating, and with all parts played by men.  [By the way, Rosalind in the story is a girl who disguises herself as a man, which means in Shakespeare's time there was a male actor, pretending to be a girl ... who was pretending to be a man]

Innovation and change of course comes from taking those gambles, and chancing/limiting when they don't quite pay off.  But it's worth it because there are no immutable rules in any field, be it theatre or testing.

Which nicely brings me to the Test Sheep's gamble of yesterday - for which you may have seen the Tweet ...

Okay - excuse the grammar (written on a phone), but you get the idea!  Yes indeed, I'm moving on for a few months to help with another project.  Unfortunately we have a very small project where work comes through somewhat ad-hoc, and when it does come through, is typically a one-person task.

The problem is that there's no assurance when work comes through that there will be the same person available to test, and only a few people have experience of the system.  For one of our key projects as discussed previously, we not only have a team culture, but a supporting handbook for the project.

The best way to onboard someone onto a new system is to talk them through it, and "let them explore and experiment" to get to know the system.  But you can't just explore without some guidance (unless the pages have help or are obvious).  Some guide is useful.

Sadly even at this point there wasn't time to write and screenshot the instructions.  This is where that XBox-generation son of mine came in, he was looking up some how-to-guides on YouTube, and I had a cunning plan!

It's true - turn to Google, and ask "how do I...", and more than likely you'll end up with a whole load of YouTube links.  Video is a method we're increasingly getting experience of using to learn.

I figured I could do a screen recording with a headset talking through the important attributes (both business and technical) as I performed several key tasks on our system (especially those non-intuitive tasks). I have to say everything on our system is documented, but that doesn't really mean if I gave all that documentation to a new tester that they'd know where to get started.

My reasoning for recording a series of screencasts was I could achieve in about a day what it would take a week and more to achieve in writing a handbook.  It sounded too good to be true.

And it was!  There were some difficulties namely,

• Screencasting software isn't "just available to download", it costs.  I tried some software out, and hated it.  Fortunately from my stop motion work I had a copy of AVS Video Editor.  The problem was it ran (and was locked to) my very old Vista machine.  Vista!

• Thankfully my target audience was other peer testers, because the videos are not slick, and involve some fumbling "oh wait ... I'm not on the right page".  To get something good enough to show-and-tell a customer, you do really need thorough knowledge of the system, and (shock horror) be working to a script.  So closer to a week than a day there!

• Vista.  Well to be honest it's an old laptop, and I was running a lot of applications on it, so it's 2GB memory struggled, and occasionally the IE browser I needed to use just "stuck", but even that pailed into comparison next to everyone's favourite, the blue screen of death that would happen if my video was too long ...

This path had risks to it - mainly that by the end of it, I'd have used up a day or more, with no real gain, and be stuck trying to do the handbook again (and being a day behind on that).  To that it became important to know "how long to spend on this before I need to see results?".  Thankfully my technical problems only wasted a few hours, but I needed to be mindful if I kept having problems on when to just abandon the project and do things "more traditionally".

It was also not only untried, but even when finished, I had the feeling of "cheating".  Somehow onboarding instructions should be a Word document, we're just so trained to it like Pavlov's dogs.  Videos felt "wrong" somehow.

Yet all the same, the purpose of the material, whether video or Word document is to educate new testers.  The media through which that is achieved is not as important as the acid test of if people can learn from what you've produced.  Certainly there was a lot of Twitter support last night for the concept ....

What I realised last night is that just like the As You Like It production last night, I won't "be proved right", I'm just enjoying as we all should, and opportunity to experiment, try something new, and if it works, maybe evolve our approach.  It's not about being proven right, it's taking the leap and freedom to try something new, and by doing so not feeling trapped by convention we feel we have no control of.

In our own way, every week we should be taking risks, trying something new, but knowing when somethings "not working" and to cut our losses.  Thats how we evolve our approach to what we do, much like that first theatre that used (shock horror) female actors to play female characters!

[Of course all that got put "on drugs" by the British convention of pantomime where typically the hero is a female playing a male, and there's a pantomime dame, played by a guy.  Typically most pantomimes end with a double wedding of the (female hero) and damsel, as well as the pantomime dame and their (male interest).  Same sex marriage, and in front of the kids!  And yet it's only lately that some people are getting horrified by the concept!]

Testing is just "as per requirements" right?

A couple of weeks back, I was witnessed some brilliant observations by testers on Twitter that "testing is about more than as per requirement".  [I believe this was started by Michael Bolton, but I can't now find the originating Tweet].

This obviously at first is a very difficult idea to get to get your head around for some testers.  Lets face it most of our test ideas, especially scripts, are derived from these requirements.  And when we have a project without much in the way of requirement, it's quite unnerving, because we feel we're operating in a vacuum, and don't know exactly how to start.

But of course, requirements are fallible and prone to a certain type of error themselves if we take them as the only source of gospel truth.

There is an example of this which I really hope people are familiar with - if you've not watched it yet, can I please encourage you to watch this video of Spinal Tap's Stonehenge.

The real Stonehenge

If you're not familiar with it, here's the story ... Spinal Tap are a controversial (and fictional) British rock band.  For one of their songs, dedicated to the monument and druids of Stonehenge, they decide to have a prop for their act the represents the ancient stones.  So they draw a design, which their manager passes to a production company.

Stonehenge Design - your requirements, if you will

So off the design goes, until the production company comes back to the manager with what they've built.

Stonehenge Prop - are you telling me this is it?

The manager thinks it's wonderful, until he says "this is just the prop yeah"?  The production company says that no, this is it.  They built to design, 18 inches by 18 inches.  Someone it seems meant it to be 18 feet by 18 feet.  Yes, there was a fundamental flaw in those requirements.

The manager (god bless him) tries to pass off the prop, and the band end up seeing it for the first time during their song, bewildered about just why they have a version of Stonehenge that's in peril of being trambled by a dwarf ...

Even next to a dwarf, this monument does not impress

There's a serious point to this, if you hand someone a design, and tell them "just build this", you're going to probably get exactly what you asked for.  But it may not always be what you wanted.

Short of having accurate requirements or being a mind reader, how can the production team really achieve this?  This is why although requirements are an important oracle, they're not the only one.  This is why many disciplines of testing, talk about needing to understand not just what the client wants (which really is the requirements), but why they want it.

Had a discussion with the band taken place, I'm hoping that the production company would have heard, "this is for our song Stonehenge, we want it to dominate the stage, and look really impressive as these dwarves dance around it".  It's at this point, handing over the design, the company might have gone "dominate the stage ... at 18 inches?", to query and probe what they've been asked for, and hopefully deliver exactly what the customer wanted.

Of course, had that happened, we'd have lost what for me is one of the funniest comedy moments of all time ...

Quality Auditing - A bad review worth having ...

I was taking another look at Lessons Learned In Software Testing on Amazon today.  I've used the work copy extensively, and really want "my own" edition, but I'm torn between having a paper copy or an electronic version (I use my Kindle a lot).

I have to admit I've not really finished it yet - but I do find it full of useful insights.  I often read things in there that I'm afraid to say I agree with, because I've seen companies and projects learning the hard way.

What interested me was the reviews, or rather the profile of the reviews ...

Most people think it's an amazing and indispensable book ... except 2 people who think it's dreadful (out of 50, that's about 4%).  Fascinated, perhaps with a shade of rubber neck syndrome, I had to look at these reviews.  Maybe these "thought leaders" of testing had an interesting take on the book, that I should not be dismissive of.

This is by far the more interesting ...

Promises Much, Delivers [little]

This book was praised by several colleagues as THE way to work on testing methods and thinking. After reading it and talking with each of them, it was apparent they were excited based on false credentials about ideas that were easy and comfortable but ineffective long term. 

This book is VERY dangerous to a serious testing organization because it focuses on minimal documentation (which means in 6 months when you're asked if you tested X and you can't remember, you'll get 5mins to get out of the building), downplays automation in regression testing (what!!?), and admits openly that it is proposing ideas that are NOT proven (contrary to what the title states) but rather are ideas that "seem to be working" (see pg 176) but no formal nor long term studies support their claims. 

Well, long term studies that have already been done directly contradict their findings: process is driven by a need to be effective and if you don't know what you're doing before you do it, then you don't know what you did when you're done. ... This is a book for those who advocate ad hoc testing to their own discredit and need a means of justificating their apathy and laziness to those who actually know effective testing techniques.

Now that is a bad review worth having!  Sadly I am surprised that this form of opinion represents only 4% of people - though the figures are going to be skewed by the fact that people who feel as the above individual are (I seriously doubt) unlikely to buy this book.

But this view, represented by, let's call him for simplicity Rex, is one many software testers have to face.

The phrase that struck me with a level of absolute terror on Rex's thought leadership style was that piece here, "it focuses on minimal documentation (which means in 6 months when you're asked if you tested X and you can't remember, you'll get 5mins to get out of the building)".

That isn't a model of testing - that's a model of QA, in this case Quality Auditors.  In his model, QAs go around as almost accountants of software recording, noting, writing.  Constantly writing more and more reports and documents which just stack up.

I have to admit early in my career I worked for a project like that (to be honest we didn't know better).  When we ran a "formal test", we needed three people - one to read the script, one to perform the action, and a third person who "witnessed" our test,

• at the end of a successful step, the reader would tick a box in the printed hardcopy of the test script.  
• at the end of a successful test case, we'd each sign our relevant roles
• at the end of a successful test phase, all our signed test scripts would be filed in our office in case of audit

And sometimes we'd have the customer come along to witness one of our tests - so we'd have a special signature box for those occasions too!

Pretty soon of course, the office just couldn't keep up with all the paperwork we were generating.  In truth we were probably now a fire hazard.  We looked like something from the movie Brazil ...

What we eventually learned was that having up to four people witness every test step, was kind of inefficient.  Oh sometimes it was worth having two people testing together to challenge each other, but mainly it was a waste, slow, boring.  At the end of my two years there I heard two testers running one of my scripts and I was actually ashamed of how slow and boring I'd made testing on the project.

The problem with the Quality Audit model of testing is this,

• just because you're recording everything you're doing doesn't mean you're doing the right thing.  It just means you can defend what you did.  And if you missed doing something because (a) people wouldn't give you feedback or (b) you were committed to following your scripted planned process, even though you found issues, then too bad.
• you're to blame for software.  Notice in Rex's take on testing, if there's a problem with the software, it's not the project manager, the developer or the BA who is made to pack up their desk.  It's the tester.  The "QA tester" here is the fall guy - he owns quality, so if the product has issues it's because he didn't add quality at the end - fire him!  Why would anyone want to work in that role?  Personally I'd rather be a Wedding Planner in The Game of Thrones!
• it creates the idea of testing being "just a very bureaucratic layer of software development".  We had three people performing one test - and doing it by slowly reading instructions and performing them.  Did we get the best value from those three testers using that model?  Hell no!  But the documented process was to die for, and would keep our auditors happy!  This leads to the idea many managers have that testing is full of waste.  Yes we do need to document anything important (see my piece on exploratory testing for more), but to give the most value for our testing time, we need the most amount of time either with hands on the software, trying out different ideas and pathways.

Of course the problem with the last point on bureaucracy is inevitably testing finds itself squeezed, and it's very tempting to do the wrong thing in that position (you keep the level of documentation, but test less yes?).  As I've said, I'm a huge fan of using tools like QTrace which just make notes for me as I test, so I don't need to either follow a script or take time consuming screenshots as I go.  Sometimes I know I have a problem area, and I want to try a few things out, and having it recorded helps be go back and show someone.  But even so if a recording doesn't show something, I don't just save it "just because" I want to avoid building up a huge library of files if I don't think there's anything useful in that file.

Testing isn't about auditing software, it's about trying things on your software (the actual doing, not the documentation).  Probably the documentation that matters the most are bug reports - but even so I see test managers who have a hard time coping with teams who deal with defects that can be fixed easily "using sticky notes" because they can't use their tool to "see what defects were fixed 6 months ago".

I'm glad I see less and less "thought leaders" like Rex.  Their ideas to software and to testing are pure bureaucratic toxicity.  They imagine a career path that as long as you can generate a documented trail of evidence you can claim the high ground with any project stuff up.  I think somewhere down the line, Rex is in for a nasty shock ...

I'll wrap up with a superb and concise quotation from Scott Barber to one of the reviewers,

"This review makes it clear that what you really want is to not have to think. Testing is a thought-engaged activity. I suggest that if you want to be told the "only" way to do a thing, that testing might not be the best career path for you."

Your welcome - you're grammar challenge

For me, grammar is a bit of an odd thing.  I was a child of the 70s, and the thinking of the UK educational system I was a part of was that you taught people how to use the English language more through repeated use and examples, than applying terms and rules and assessing them on that.

It's interesting, because I do a good job with writing (not perfect, but hey, this blog and a couple of books isn't bad).  Grammar I'm not bad on, however I'm actually partly dyslexic, and my spelling is pretty terrible - thankfully I've learned a few tricks to hid it, such as a reliance on the red underline on Word documents to warn me I might have made a boo-boo.  [Typically I go ballistic when someone turns that feature off, as it's part of my coping mechanism]

I've been able to use the language quite well, to University academia standards and beyond.  But people are sometimes surprised to know I struggle to know what a verb and a noun is.  We were taught to use the English language without the labels.  In fact in many ways I've learned more recently about this through my son as he goes through education himself (and as per the norm, names and labels are back in vogue).

It's impossible to avoid some of the grammar memes which are floating about social media.  Mainly I find them quite fun, and educational.  Although I find some can be posted from grammar bores.

This though has to be one of my favourites,

Now this is a grammar rule that I definitely know - the difference between,

• your - meaning an item that belongs to you such as your ball, your vanity, your blog
• you're - a contraction of "you are", examples being you're vain, you're annoying, you're welcome

What's fascinating though is despite be knowing this rule quite well, I'll often reread something I've written on here or in one of my books, and notice despite knowing this rule, despite having reviewed my material (in the case of my books, externally), I will occasionally make the mistake of using the wrong form.

This fascinates me - indeed it's the basis of software testing.  Even when we thoroughly know a form like the English language, we'll occasionally make an "oops".  So any form of writing can be subject to these errors, and this obviously goes for coding as well.

If people were capable of never making these forms of mistakes, we'd need less testers, proof-readers and the like.  But of course, it's human nature to make these mistakes - and whilst we can take actions to minimise them, we can never take action to remove them altogether.

The communication challenge ...

A couple of weeks ago there was a video going viral on social media called "The Expert, A Hilarious Sketch About the Pain of Being the Only Engineer in a Business Meeting" ...

It's a very funny sketch, and many people have commented that "I have been in that meeting".  Business people don't get what technical people say - drum roll and big laugh please!

Now here's the challenge.  If you were the technical person in that room, how would you try and take charge of that meeting and prevent that car crash from happening?  The technical expert tries his best, but could you do better?

The challenge from me to you, is that rather than laughing "business peeps iz sooo stupidz", how could you turn situations like this around?  Because I guarantee you that you will be faced with at least one such meeting - if you have your sights on being senior, it'll happen more and more ... because you're the expert remember!

When I left Assurity to join Kiwibank, part of the fun and challenge was leaving a technical environment to one where I would be one of the few technical people in a predominantly business area.  I talked a little about this experience when I looked back at test estimation.  There's no doubt that like The Expert, I made a whole heap of mistakes, mainly by assuming my audience had a similar background in IT to myself.  But instead I often worked with people to whom the IT solution was a means to an end, and that meant I had to get into their headspace a little first.

Though I never got perfect, I certainly got better. And a major way of doing that was replaying conversations like the one in The Expert and asking "well ... how could that have gone better".  Give it a go ...

Stand Up For Whirlwind ...

Back when I talked about support for mental health, I mentioned the good work of the Whirlwind guys up on Kapiti Coast in New Zealand.

I'm very pleased to announce that a group of Whirlwinders including myself will be doing an evening of comedy on Thursday 29th May at the The Jolly Pub in Paraparaumu.

If you'd like to support this worthy cause, tickets are $10 each (including spot prizes), and you can order yours by contacting Martin Sloman.  If you can't make the event, I'd still encourage you to take a look through the Whirlwind website, and view the amazing work that Whirlwind's behind.